JavaScript Signals proposal прийнято до розгляду комітетом TC39

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Нещодавно всі, хто слідкує за розвитком JavaScript, активно обговорювали proposal на додавання сигналів в стандарт EcmaScript, а вчора цей документ просунувся в процесі на stage 1. Це друга стадія розгляду нових функцій, якими пропонують розширити стандарт мови (усього їх 6). Це означає, що комітет ТС39 визнав потенційну цінність сигналів і погодився розглянути їхню подальшу імплементацію.

Отже, що таке сигнали? Це елемент реактивного програмування, мета якого зберігати стан застосунку і сповіщати підписників про зміну цього значення. Фактично сигнали — це імплементація Observer патерну.

Насправді це не зовсім нова ідея. Один з перших популярних інструментів, який застосував схожий підхід, була бібліотека knockout.js. У ній використовувалися observebles для прив’язки даних ViewModel об’єкта до елементів розмітки. Наразі ця бібліотека вже не розвивається.

Серед сучасних інструментів «нове життя» цій ідеї принесла бібліотека Solid, в якій управління станом застосунку (state management) побудовано навколо сигналів. Нижче приклад коду найпростішого використання сигналів із сайту SolidJS .

import { render } from "solid-js/web";
import { createSignal } from "solid-js";

const [count, setCount] = createSignal(0);

setInterval(() => setCount(count() + 1), 1000);

function Counter() {
    return <div>Count: {count()}</div>;
}

render(() => <Counter />, document.getElementById('app'));

Згодом свої імплементації сигналів почали з’являтися і в інших бібліотеках:

Інша сторона такої популярності — «зоопарк» імплементацій, які несумісні між собою. Тому автори документу досить добре попрацювали із розробниками бібліотек і фреймворків, разом із переліченими, щоб підготувати максимально вдалий для всіх варіант. Серед наступних кроків розробка прототипу і його інтеграція в кілька інструментів, щоб перевірити життєздатність ідеї.

Ознайомитися з документом proposal можна тут. Також про мотивацію і деякі технічні деталі можна прочитати в блозі автора Rob Eisenberg.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
розгляду комітетом

Если что-то делает именно «комитет», то значит это нахрен не нужно. Независимо от языка.
Комитеты это бесполезная шляпа, что сидит на грантах, донатах, какого-то другого рода подачке и занимается ИБД.

Хто як не «комітет» має вирішути, що додавати у новий стандарт мови програмування?

Залишилось зрозуміти нахіба воно в JS. Це явно рівень фреймворків, при тому фронтенд фреймворків. Десять років декоратори не можуть викотити, зате розпиляються на нішеві штуки, хоч це тільки і 1й стейдж.

Хоч сигнали зараз і популярні в Front-End фреймворках і бібліотеках, але не бачу суперечності у використання їх на бекенді, як один з інструментів реактивного програмування. Вони незалежні від рендерингу. Але так, основні зацікавлені сторони — на стороні фронтенду.

але не бачу суперечності у використання їх на бекенді,

Те що можна використовувати не означає що воно там потрібно і тим більш не настільки потрібно, щоб це реалізовувати на рівні рушія JS. Це не якась низкорівнева фіча, яку на JS не вирішити, типу слабких посилань і дотичного (WeakMap, WeakRef, FinalizationRegistry), а JS це далеко не тільки фронтенд, чи навіть бекенд, купа всяких embedded систем, яким доведеться цю пургу реалізовувати під кожне віяння моди, бо одним подавай функціональне, іншим реактивне і т.д.
Надіюсь що завернуть та не будуть загажувати VM, чи просто запозичать якісь низько рівневі generic фічі для оптимізації існуючих рішень на JS.

Там суть в том, что можно будет писать useEffect без массива зависимостей, они будут выводиться автоматически. ОП где-то в облаках витает, зачем нужен был в ОП-посте этот SolidJS если мог бы просто примеры нового API скопировать с ридми.

Ти не правий, це ніякий не рівень фреймворку, це звичайний синтаксичний цукор для Observer паттерну, який прям чудово вписується у фронт.

от саме тому що воно синтаксичний цукор і «прям чудово вписується в фронт», а не в бек (+IoT), йому і місце на рівні фронт фреймворку чи бібліотек с реактивними штуками для поціновувачів. Задача мови чи платформи надати продуктивний низькорівневий інтерфейс для Observer, щоб не доводилось руками звіряти знімки об’єкту та вираховувати дельту зі здоровенним оверхедом, як це було колись до його появи. Цукор по визначенню не привносить в мову/платформу нічого крім іншої семантики поверх існуючої, тому він тривіально може бути реалізований на рівні бібліотеки, що робить більш чистішими рушії, а не тащить його по шляху пхп де 100500 схожих функцій в перевантажених інтерфейсах. JS був завжди лаконічним і з зворотною суміснісю, рівня якої мабуть не було в жодні іншій екосистемі. Де гарантія що хіпстери не награються цими сигналами, а далі який бородач зі сцени скаже що це «вчорашній день» і воно буде висіти мертвим вантажем, який тим не менш доведеться підтримувати всім розробникам рушіїв?

Підписатись на коментарі