Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A proposal to add signals to JavaScript

github.com

Post reply on HN
Print view View original

11–20 of 336 posts

Re: A proposal to add signals to JavaScript

#11

Post by lambdaba »

This looks very much like mobx, which is my favorite JS effect system.

Here is the mobx version:

  import { observable, computed, autorun } from 'mobx';

  const counter = observable.box(0);

  const isEven = computed(() => (counter.get() & 1) === 0);

  const parity = computed(() => isEven.get() ? "even" : "odd");

  autorun(() => {
    element.innerText = parity.get();
  });

  // Simulate external updates to counter...
  setInterval(() => counter.set(counter.get() + 1), 1000);

Re: A proposal to add signals to JavaScript

#13

Post by ivanjermakov »

Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)?

I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library?

I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.

Re: A proposal to add signals to JavaScript

#14

Post by pavlov »

__s wrote: post #7

Promises are a nice success story, but without async/await it wasn't really necessary to standardize > The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more… Would be interested what existing library authors think of this proposal. Interesting that React is not in that list Signals are a bit like c…

> “Interesting that React is not in that list”

Signals are not a part of the core React API, unlike Preact.

My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.

Re: A proposal to add signals to JavaScript

#15

Post by mg »

When I need to signal something across my application, I use events:

    window.dispatchEvent(new Event('counterChange'));
And every part of the application that wants to react to it can subscribe via

    window.addEventListener('counterChange', () => {
        ... do something ...
    });
Anything wrong with that?

Re: A proposal to add signals to JavaScript

#18

Post by ivan_gammel »

ivanjermakov wrote: post #13

Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)? I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library? I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.

>In other words, can't this be a library?

It is explicitly mentioned in the proposal. The problem with 3rd party libraries is their interoperability and diversity of implementations, which might be unnecessary for this kind of things.

Re: A proposal to add signals to JavaScript

#20

Post by makkesk8 »

Looks useful, but what baffles me is.. Why is every framework setting state or their "signals" using "setX" functions? What's wrong with the built in getter and setters that you can either proxy or straight up override?

This feels arguably cleaner: something = "else";

Than: setSomething("else");

Post reply on HN