31–40 of 63 posts
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.
Earlier quoted context omitted.
Same here, I have been spreading mobx everywhere I have gone. There's usually some resistance but once people got used to automatic dependency tracking, they never go back. 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!
I recently started ripping Mobx out of my app. Mobx solved exactly 1 problem for me, which was passing data horizontally (to siblings/cousins) and even to non-React components. 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'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.
Earlier quoted context omitted.
I recently started ripping Mobx out of my app. Mobx solved exactly 1 problem for me, which was passing data horizontally (to siblings/cousins) and even to non-React components. 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).
That appears to be in beta still? What store are you using with it? 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:
Earlier quoted context omitted.
Because it's nicer. The mental model of reading the functions using signals is; it's all about initialize|constructor|new function. And then those off-jsx stuff starts to make sense since you won't re-initialize those things. They need to exist somewhere in particular execution model. In Solidjs, it's effects (compiled from jsx where signals are read). I think those who are familiar with static type languages, natura…
When you have a big app, it becomes a spaghetti mess, and I speak from personal experience having to untangle that spaghetti.
The state has to go somewhere, curious how you choose to handle it.
Earlier quoted context omitted.
When you have a big app, it becomes a spaghetti mess, and I speak from personal experience having to untangle that spaghetti.
What approach do you prefer for big apps? The state has to go somewhere, curious how you choose to handle it.
Nope.
I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…
I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…
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)
Earlier quoted context omitted.
Because it's nicer. The mental model of reading the functions using signals is; it's all about initialize|constructor|new function. And then those off-jsx stuff starts to make sense since you won't re-initialize those things. They need to exist somewhere in particular execution model. In Solidjs, it's effects (compiled from jsx where signals are read). I think those who are familiar with static type languages, natura…
When you have a big app, it becomes a spaghetti mess, and I speak from personal experience having to untangle that spaghetti.
I don't really understand why people like signals again. I used a signals-like reactive programming model in VueJS a while ago and hated that you could never be sure exactly where things were being changed. Thankfully it seems that the React creators and maintainers are not hopping on the signals train and are instead adamant about unidirectional dataflow with explicit mapping of state to UI, which, as has been the r…