3 ms·

It's great to see people moving in this direction, but I'm disappointed that everybody has decided to reimplement basically the same thing independently. Mobx

It's great to see people moving in this direction, but I'm disappointed that everybody has decided to reimplement basically the same thing independently. Mobx was ahead of the game here (though, granted, it too draws on Knockout.js). You can use Mobx to declaratively describe reactive state, much like this. But it isn't integrated into any framework - you can use it in vanilla JavaScript with no other runtime or compilation required. You define models with Mobx, then on top of that there's mobx-react, which ties your model into React's update APIs (essentially making render() automatically observe values, and making relevant changes trigger a re-render), or there's mobx-vue, or mobx-svelte, or mobx-preact, etc etc. Decoupling this is super helpful - for example I'm using mobx to model raw state, computed state & reactions to changes in server side Node.js, no problem. Meanwhile, recreating the same reactive concepts independently in each library instead makes all the resulting code incompatible, so even your pure JS state models are coupled to your UI framework - e.g. createCounter in this post has to import & use $state from Svelte. That makes it far harder to change frameworks in future, hard to share code between apps using different frameworks (plausibly even different versions of the same framework), etc etc. I'd love to see a native common standard for this, similar to how promises were eventually standarized and suddenly everything had a compatible model for handling async future results (I could swear I've seen initial discussion on exactly that already, but I can't find it anywhere now sadly).

jauntywundrkind 3y ago
It kind of had to get sent back to the drawing board to work well (avoid all the absurd one-at-a-time limitations of generators), but async-iteration-helpers I think will be an incidental huge help in normalizing/nudging the consumer api into "just an async iterable". Updating/writing state might be more complex, speak to the implementation, but seeing things change should have a semi-standard api. https://github.com/tc39/proposal-async-iterator-helpers https://github.com/tc39/proposal-async-iterator-helpers One huge sadness I have is that when you have a callback in .then or .next, your handler doesn't get a gratis reference to what you were listening to. I'd love to have this be a better record. DOM is so good about having thick events that say what happened, and it's so helpful, sets such a rich base, but js snubbed that path & left passing data in 100% to each event producer to decide as it will. Consumers can craft closures to seal some data into their handlers but it sucks compared to having an extensible data flow system. We're kind of sort of finally fixing this crime the hard way by standardizing async context/async_hooks, which is a whole new ambient way to create context that we can enrich our async events with, since there was no first class object to extend for having omitted passing in the promise to the promise handler. https://github.com/tc39/proposal-async-context https://github.com/tc39/proposal-async-context Also worth pointing out, maybe arguable as a hazard tale, observables was proposed a long long time ago. There's still a ton of adoption. But it also feels extremely similar yet notably apart & worse ergonomics than async iteration. It's imo a good thing it didn't get formalized. https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable Alas one reactivity I really wish we had had is object.observe (note: different API than observables), or something like it. Undoing good specification work & saying, 'yeah, if users want it, they can implement it themselves with proxies' has lead to no one doing it. And you can't just observe anything; whomever is the producer has to up front make the decision ahead of time for all consumers, which turned a great capability into something first boutique then quickly forgotten. Alas! https://esdiscuss.org/topic/an-update-on-object-observe https://esdiscuss.org/topic/an-update-on-object-observe I ack your ask, and there's no shortage of options that are pretty damned good. But I feel like we are still in a discovery not deployment phase, still delay competing because we have a lot of terrain and idea space to consider. Before we pick, standardize & ship one.
gabeidx 3y ago
You may be thinking of the ECMAScript Observable proposal: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable
pier25 3y ago
I loved MobX. Used it for years with React and Inferno. But not only it's an added layer of abstraction, it's also a complex piece of machinery which is not needed when the framework solves reactivity. When I started using Svelte back in 2019 I was very happy to let go of MobX.
Rapzid 3y ago
This is the way. Mobx tc39 decorator support is pretty much done too. I check in on the PR weekly haha.

jauntywundrkind 3y ago

It kind of had to get sent back to the drawing board to work well (avoid all the absurd one-at-a-time limitations of generators), but async-iteration-helpers I think will be an incidental huge help in normalizing/nudging the consumer api into "just an async iterable". Updating/writing state might be more complex, speak to the implementation, but seeing things change should have a semi-standard api. https://github.com/tc39/proposal-async-iterator-helpers https://github.com/tc39/proposal-async-iterator-helpers One huge sadness I have is that when you have a callback in .then or .next, your handler doesn't get a gratis reference to what you were listening to. I'd love to have this be a better record. DOM is so good about having thick events that say what happened, and it's so helpful, sets such a rich base, but js snubbed that path & left passing data in 100% to each event producer to decide as it will. Consumers can craft closures to seal some data into their handlers but it sucks compared to having an extensible data flow system. We're kind of sort of finally fixing this crime the hard way by standardizing async context/async_hooks, which is a whole new ambient way to create context that we can enrich our async events with, since there was no first class object to extend for having omitted passing in the promise to the promise handler. https://github.com/tc39/proposal-async-context https://github.com/tc39/proposal-async-context Also worth pointing out, maybe arguable as a hazard tale, observables was proposed a long long time ago. There's still a ton of adoption. But it also feels extremely similar yet notably apart & worse ergonomics than async iteration. It's imo a good thing it didn't get formalized. https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable Alas one reactivity I really wish we had had is object.observe (note: different API than observables), or something like it. Undoing good specification work & saying, 'yeah, if users want it, they can implement it themselves with proxies' has lead to no one doing it. And you can't just observe anything; whomever is the producer has to up front make the decision ahead of time for all consumers, which turned a great capability into something first boutique then quickly forgotten. Alas! https://esdiscuss.org/topic/an-update-on-object-observe https://esdiscuss.org/topic/an-update-on-object-observe I ack your ask, and there's no shortage of options that are pretty damned good. But I feel like we are still in a discovery not deployment phase, still delay competing because we have a lot of terrain and idea space to consider. Before we pick, standardize & ship one.

gabeidx 3y ago

You may be thinking of the ECMAScript Observable proposal: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable

pier25 3y ago

I loved MobX. Used it for years with React and Inferno. But not only it's an added layer of abstraction, it's also a complex piece of machinery which is not needed when the framework solves reactivity. When I started using Svelte back in 2019 I was very happy to let go of MobX.

Rapzid 3y ago

This is the way. Mobx tc39 decorator support is pretty much done too. I check in on the PR weekly haha.