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 скопировать с ридми.

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