What Are Signals?(signia.tldraw.dev) |
What Are Signals?(signia.tldraw.dev) |
This is a good thread about their drawbacks [2]. Apparently, both the below examples actually do different things:
function One(props) {
const doubleCount = props.count * 2;
return <div>Count: {doubleCount}</div>
}
function Two(props) {
return <div>Count: {props.count * 2}</div>
}
[0] https://twitter.com/jordwalke/status/1629663133039214593
[1] https://twitter.com/dan_abramov/status/1629539600489119744
[2] https://twitter.com/devongovett/status/1629540226589663233
1. The function is called only once at component construction, and never again. Unlike React, it is _not_ called for every render.
2. Every expression in `{}` is compiled to a thunk function - not to a direct JS expression.
For example, the expression
<>{props.count * 2}</>
memo(() => props.count * 2)
Ideally, signalling shouldn't be retrofitted on normal variables. It assumes then that you overload variable access (assignment and reads). Then it's hard to know which variables are reactive and which ones are not. The problem stems from the overloading of semantics.
A UI is mutable so it's not about mutable state being wrong but the unit of variability are not program variables but rendered props which are basically DOM Element properties. In react, it just happens that it uses variables whose values are injected in the DOM elements via jsx but that's an issue (especially when dealing with exports, prop drilling etc)
So until a plain variable and a reactive variable are made to look different everywhere in code, it will remain confusing. And even then, it's not optimal.
Disclaimer: I'm currently implementing a cross-platform UI framework in Go and that's the reason why I had to think about it since traditional languages do not have reactive variables.
I’ve implemented this pattern with mobx and those two pieces of code are equivalent.
In my opinion:
- Unidirectional data flow patterns prevent a class of problems junior developers tend to make but require much deeper discipline to keep the app understandable
- Conventional bi-directional data flow patterns are susceptible to junior developer mistakes but generally are hard to make unreadable
If you don't like what Solid is doing you may consider it a self-inflicted wound, nothing is forcing Solid to work that way.
I love signals in VueJS, and it doesn’t even preclude a redux-like/lite state- management library like Pinia.
https://vuejs.org/guide/extras/reactivity-in-depth.html#conn...
"patch languages" like PureData, Max/MSP/Jitter, QuartzComposer are much better interfaces to work with signals ... Or rather with signal processors.
- The Evolution of Signals in JavaScript, https://dev.to/this-is-learning/the-evolution-of-signals-in-...
- React vs Signals: 10 Years Later, https://dev.to/this-is-learning/react-vs-signals-10-years-la...
- Making the Case for Signals in JavaScript , https://dev.to/this-is-learning/making-the-case-for-signals-...
Those two code examples are different because that's the tradeoff that Solid made. It allows Solid to track changes in a uniform way even if the data isn't inside a component. Because in Solid components are just a way to organize code, not a unit of rendering (like in React).
And on top of that if you think that React still somehow has unidirectional data flow, it doesn't. Hooks make it anything but unidirectional. And not that different from signals: https://res.cloudinary.com/practicaldev/image/fetch/s--upMC6... But often less predictable.
See also The Cost of Consistency in UI Frameworks, https://dev.to/this-is-learning/the-cost-of-consistency-in-u... which is slightly related to this.
It is hard to even make sense of the discussion without imagining the details of how those frameworks are implemented. And the discussion on the level of normal usage, not something advanced or development oriented.
Then I thought for a moment it was talking about a "signal" in the information theoretical sense
All I came away with was that they've invented a new name for event driven architectures and/or data flow programming.
I know naming is hard but we need to stop overloading terms.
the key difference is in backpressure strategy: signals are canonically lazy, they don’t compute or do work until sampled, and only the latest value is relevant (nobody cares where the mouse was a moment ago when nobody was looking). streams are eager, you can’t skip a keyboard event or a financial transaction, even if the pipes are backed up – instead you have to tell upstream to slow down so you can catch up. The benefit of event streams is the guarantee that you'll see every event, which means streams are suitable for driving sequences of side effects (keyboard event -> network request -> database transaction).
signals are a good fit for rendering because you only want to render at up to say 60fps (even if the mouse updates faster, which it does). and you only want to render what’s onscreen, and only when the tab is focused. rendering (say dom effects) is indeed effectful but not in the discrete way; the dom is a resource, it has a mount/unmount object lifecycle, and due to this symmetry it is a good fit for rendering whereas isolated effects (without a corresponding undo operation) are a terrible fit for signals because backpressure will drop events and corrupt the system state.
You can use streams for rendering too, but it's dis-optimal, and potentially by a lot. If your app chokes on a burst of events, you want to skip ahead and render the final state without bothering to render all the intermediate historical states. Signal laziness is what enables this "work skipping"; a stream would have to process each individual event in sequence.
I have no idea if JS projects get the backpressure right, can anyone confirm?
To discuss more specifically TLDraw’s Signia library, I think the ability to do manual diff tracking & incremental updates for computed stores is an interesting “escape hatch”. Docs here: https://signia.tldraw.dev/docs/incremental
Most signal libraries I’ve seen try to lean hard into magic auto-tracking of dependencies which means they make it really easy for the developer to correctly observe a lot of dependencies, cool on correctness, but then have a very limited set of tools to deal with the performance implication of some computation needing to re-run a whole bunch. The differential tracking here means that if you see such a hotspot, you can get really manual optimization of recomputation without needing to squeeze into the libraries pre-packaged observable collection API.
Downside of this API is it seems quite easy to get it wrong.
Another thing I like about Signia is the use of logical time. I saw this first in Jotai internals, then in Starbeam. I haven’t dug into the source of the library yet but I think logical time is a good approach and makes inspecting internals make a bit more sense than inspecting systems (like Notion’s) that rely purely on update notification listeners.
Subscriptions grow from the leaf up to the root (which is a single app "db") and so computation is minimal. If something writes to the "db", only relevant subscriptions are recomputed and only views subscribing to those are "repainted".
Works like magic.
PReact's signal() as a concept is better - more pure. https://preactjs.com/guide/v10/signals/
Nope.
Now they're back, baby. Happy to see them used again, even if we've had to razzle it up a bit with a new name.
Still, it is unfortunate that the article begins with “Let's start with an extremely broad definition” (of signals), then continues with what sounds like signals in general, mentioning React only as an example, but then turns out wanting to only talk about signals in the particular reactive UI sense common in web development, without properly introducing that narrowing of focus.
I guess that focus can be expected from a blog on a site about a TypeScript signals library, but from the way the first few paragraphs are written, it’s certainly confusing when reading the article without further context, coming from HN.
Was confusing then and is still confusing now.
(a) A thing that happens (or might happen but ultimately doesn’t) and is associated with a value of some sort, such as the mouse coordinates of first left-button click the program sees;
(b) A list of the above with monotonically increasing times, such as all the left-button click coordinates in order;
(c) The above plus an initial value, representing a piecewise constant function of time, such as the state of a toggle;
(d) A (conceptually) piecewise continuous function of time, such as the position of an animated object.
[To avoid “time leaks”, i.e. accidentally retaining all change history from the beginning of time, you also need
(e) A computation that reads the current time, such as the mouse coordinates of the next left-button click the program will see;
but that’s not supposed to be obvious—it took more than a decade to figure out.]
Possible names include: event occurrence [for (a)], event stream [for (b)], event [either (a) or (b)]; behaviour [(c) or (d)—the library may not distinguish them in the API or only provide (d)]; reactive [Conal Elliot’s name for (c) as opposed to (d)]; signal [(b), (c), or both]. All of these make sense in isolation. I don’t think you can win here.
[Perhaps the worst word to use is “stream“, because people start trying to fit streams with backpressure in there. FRP only makes sense as far as you can assume any recalculations happen instantaneously, meaning at the very least before the next input change happens. If you forget that, you get Rx instead of FRP, and that’s not amenable to human comprehension—or indeed sanity.]
I'm not sure what you mean by "Rx" in this context.
My background is much more in the systems (and indeed, "signals" in the theoretical sense).
I still think the name "signal" here is quite bad, since it's the abstract concept of something-that-carries-information
Because of this, Ryan Carniato of SolidJS referred to his own observable primitives as "signals" and this has become the default terminology to talk about this type of pattern within the context of web development.
Really, signals should be thought of as a type of observable.
The problem with angular 1 components (isolated scope directives) was simply that not many understood it as a best practice until far too late, and the framework allowed you to do all kinds of terrible designs like shared scope/multiple controllers per file, which was the more common way to develop. Also performance was poor.
Feel the same way about signals. Vue has been doing it for years (just not tied into render optimizations). I used a similar model via angular 1 back in 2014 even, via watch chains. Much less performant though. Can also do it via redux by defining a special third arg which defines state depenencies (which we do here).
Nothing really novel about a tree-like series of derived states. Interesting that social media is ablaze like its something new
I've seen so many projects get bogged down in props hell, then gobs of context api and performance problems when too many things react at once.
Mobx has been solving these problems for a long time now!
But now `useSyncExternalStore` solves that. No context needed. Can read and write state anywhere, even outside components. No "observe" or "track" shenanigans. Efficient updates (can listen to a subsection of the tree).
I have stopped taking seriously people that rely on novelty to sell you their next training.
So, I'd guess, something with referential transparency.
From “reactive extensions”, a name for a family of libraries[1] (RxJava, Rx.NET, RxJS), AFAIK one of the first attempted implementations of mature FRP ideas in the imperative world and one messy enough that it took React’s success for anything similar to reënter the mainstream.
Compare the enthusiastic HN reception of “Deprecating the observer pattern” in 2011[2], mostly by people who heard of FRP in the functional-language setting, and the vitriol it received in 2018[3], apparently from people for whom FRP came to mean Rx (and similarly confused things like Bacon.js). It is this vitriol that I meant to preemptively redirect by the mention of FRP ≠ Rx, so if you’re not aware of this history it’s no big loss to ignore it.
(Yes, I am very much No-True-Scotsmanning this. That should not be taken to mean that reconciling FRP with side effects is a trivial problem, though,—I’m not sure it’s even a solved one. Only that Rx and its ilk suck as a solution.)
> My background is much more in the systems (and indeed, "signals" in the theoretical sense).
> I still think the name "signal" here is quite bad, since it's the abstract concept of something-that-carries-information
I think the intention was to allude to physical wires and conceptual analog or digital things they transmit, as in “reset signal”, “differential signalling”, etc. It does seem to me to be an apt term for a (continuous-)time-dependent doodad in a program, given “variable” is taken.
Your description sounds more like the information-theoretic “channel” or “transmission medium”.
Its still not quite as nice as MobX, as passing larger objects down the component tree means you need to mix snapshot and non-snapshot state. But it makes me hopeful about `useSyncExternalStore`
I'll keep an eye on it! But mobx does more than that, like a lot of component optimizations and utilities. It's been so good for so long, I'm not in a rush to get rid of it.
Source: I'm the primary Redux maintainer, and worked with Andrew Clark of the React team to nail down the semantics and behavior needed by `useSyncExternalStore` in practice. They had the idea, but discussed a lot of the necessary use cases with us and other lib maintainers, and a lot of its internal implementation is directly related to how React-Redux's `useSelector` hook was implemented already.
I built the first working code that used it by prototyping React-Redux v8's switch from our own internal subscription handling to `useSyncExternalStore` instead and gave Andrew feedback:
And you never use only local state. You advocate for Redux in a different comment which is literally a global state where you are going to have something suddenly change somewhere from the point of view of a component.
For Redux, at least that's explicit, for signals, it's really not.
The state has to go somewhere, curious how you choose to handle it.
Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus.
And looking at the current reincarnation of this abomination, it is marginally less spaghetti, and converging on the same signals code that everyone is converging on.
The main point of Redux is that it follows functional programming paradigms of immutable data, which makes reasoning about changes much easier. Compare that to the global state everywhere of signals/reactive/observables-based approaches like MobX or RxJS.
What are you on about? Redux is literally about global state everywhere. But with three to four layers of abstractions between.
You define your state globally. Then use hooks to fetch data from that global state, and then "dispatch" aka call actions on that global state. If something else somewhere else updates data in that global state your component will be affected if it uses that data.
But it also requires you to write an insane amount of useless stuff like "define your store, then reducers, then slices, then god knows what" to arrive at almost the same code:
// redux
import { useSelector, useDispatch } from 'react-redux'
import { decrement, increment } from './counterSlice'
export function Counter() {
// note how we reach into magical global state that useSelector knows about
const count = useSelector((state: RootState) => state.counter.value)
const dispatch = useDispatch()
return <>
<button onClick={() => dispatch(increment())}>Increment</button>
<span>{count}</span>
<button onClick={() => dispatch(decrement())}>Decrement</button>
</>;
}
// solid
// state is immutable. It's also not magical, you explicitly refrence and import it
//
// increment and decrement would use a `set` function to update the store to required value
// see https://www.solidjs.com/docs/latest/api#createstore
// and https://www.solidjs.com/docs/latest/api#updating-stores
//
import { state, increment, decrement } from './counter-store';
export function Counter() {
return <>
<button onClick={() => increment()}>Increment</button>
<span>{state.count}</span>
<button onClick={() => decrement()}>Decrement</button>
</>;
}To add, this is also why I explicitly mentioned Rx and Mob, which are not as clean as the Flux architecture in terms of creating spaghetti code. And I believe we are also defining spaghetti differently. Spaghetti != boilerplate.