131–140 of 336 posts
> Within JS frameworks and libraries, there has been a large amount of experimentation across different ways to represent this binding, and experience has shown the power of one-way data flow in conjunction with a first-class data type representing a cell of state or computation derived from other data, now often called "Signals".
I didn't understand the example in the linked README. // A library or framework defines effects based on other Signal primitives declare function effect(cb: () => void): (() => void); What library? What framework? I lost here. What's effect? effect(() => element.innerText = parity.get()); How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal chang…
> How does effect knows that it needs to call this lambda whenever parity gets changed? The call `parity.get()` will register a dependency on the function that is passed to `effect()`. When `parity` is updated, the function is called. > Will it call this lambda on any signal change? Only when a dependent signal changes. In this case, `parity` depends on `isEven` and `isEven` depends on `counter`. So when `counter` is…
I'm guessing this is why they don't propose to add this function to the standard: That fact makes it not very pretty.
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(() =>…
Earlier quoted context omitted.
In simple applications it is easy. More complex it is not easy.
I’ve been writing web apps for easily 25+ years. Never have I reached for React and friends voluntarily. But again, I know I’m in a minority. I’m just not completely sure why.
But I don't think React necessary for _every_ app and it really depends on what kind of apps you are making.
Certainly you can do the original style of app where the templating is on the server and any js is just to hook up already existing nodes. The js community has more or less moved away from that "rails" style of app years ago…
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?
It can also be more performant, eg, say you have a computation that depends on 2 values:
`result = a ? b : 0`
Then if a is falsy, we don't need to recompute if b changes. This is achieved automatically with signals, but would require quite some code with classic pub/sub.
Earlier quoted context omitted.
> “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.
There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-la...
function One(props) {
const doubleCount = props.count * 2;
return Count: {doubleCount};
}
function Two(props) {
return Count: {props.count * 2};
}
More generously, JS framework design is hard. If you’re ambitious at all, you end up fighting the language and your runtime paradigms will hang like ill-fitting clothes on its syntax. The One/Two example above shows how easily expectations break in this world of extensions to extensions. There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.
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.
I believe Svelte does figure it out at build time. Which does make me question the mention of Svelte in the proposal, and makes me wonder what the Svelte developers think of it - because IIUC they indeed don't need this (at runtime), if I'm not mistaken.
Earlier quoted context omitted.
I believe memory leaks to start
Are you implying that there are memory leaks in browsers' internal implementation of events? Because my take is that the problem is with "user space" scripts not cleaning up after themselves, and I don't see how that would get better by adding yet another API to be mindful of.