[brundolf]

> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components.

This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.

[gkaemmer]

I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects.

I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

[brundolf]

It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most of the time, and you'll even get better performance in many cases because of the highly-granular pub/sub that it sets up automatically. I cannot praise this paradigm enough.

[orangecat]

And then there's Vue.js which essentially has MobX functionality built in. When you want to update the state, you just...update the state, which can be a plain JS object that knows nothing about the front-end framework. I've used it for several medium-size projects and haven't gotten close to needing anything like Redux or Vuex.

[brundolf]

Yeah, although when I played with Vue a couple years ago it seemed like it wasn't quite as powerful as MobX (particularly when you start stacking up a graph of computed values, or when you want to create side-effects of your own). But definitely a similar idea.

[phaedryx]

I was a fan of MobX+React until I to a look a Vue when version 3 came out. Now I'm a Vue fan and what I was doing before feels like overkill.

[Aeolun]

It is also fucking magic. I love it when it works, but I have no idea why it doesn’t when it breaks. The same is not true for Redux, which is so simple I can build a house with it.

[brundolf]

The "magic" is very simple and understandable if you read the docs; I fairly quickly gained an understanding of it that allowed me to dig into the odd performance issue or bug without much trouble

1) Observables are properties on objects; when their getter is called, it becomes "tracked" (subscribed to) by the currently-running tracked function. When their setter is called, it publishes to all subscribers. This happens through JS proxies for plain objects, and class decorators for class instances.

2) A tracked function is anything that must be re-evaluated when an observable it depends on is modified. This includes React render functions, computed functions, and any other side-effects you've created via autorun(), reaction(), etc. Though the idea is to avoid side-effects, so 90% of the time it's just render functions and computed functions. In these cases it amounts to a cache-clear on a pure function: "the return value will be different, so re-evaluate it and use the new return value". A computed function is an observable property getter that's also a tracked function (it doesn't have a corresponding setter; instead, it publishes when it's published to).

3) Tracking works by a) marking global state before a tracked function is run, b) making note of any observables that report back during that time, c) clearing the global state (and subscribing to the observables) when the tracked function completes. Because this is done temporally based on before/after the function has executed, any nested function calls get treated exactly the same as the top-level function call. There's no special magic necessary for that.

That's about all there is to it. Everything else in the library is just another permutation on these concepts.

[tomduncalf]

Great explanation! And keep fighting the good fight pushing MobX ;) Pretty much everyone I know who has tried it has ended up loving it, but it can be hard to convince people to give it a go (because of FUD around "mutability" or "magic" or whatever...).

[brundolf]

By the way this conversation inspired me to make this: https://github.com/brundonsmith/crowdx

It's a heavily-commented, minimal reproduction of MobX's core functionality for the purpose of understanding

[tomduncalf]

Wow, nice work! I’ll take a proper look at this later today, thanks for sharing :)