Solid immutability vs Mobx mutability and bug sensitivity

[quixot1c]

There is a lot of talk online about how immutability helps prevent nasty bugs. I get the main points that are made. However, I have trouble seeing the benefits of immutability when you compare it to Reactive programming that Mobx uses. (the fact that Solid is clearly faster than Mobx, even when compared to mobx-jsx is of course a clear advantage, but not the one I am asking about now)

Compare a Mobx Store that has some shared state in it, injected via a DI container vs a Store created with createState and distributed via Context in Solid.

The Mobx Store is a class with some @observable properties. One can disallow direct manipulation of the properties and only allow mutation via methods on the class itself, guaranteeing correct manipulation of the state. This single mutation then triggers a rerender for all Components that depend on it and also the computed values depending on it. In this way state is never stale.

The Solid store exposes some actions that allow manipulating the state in exactly the same way as the Mobx store's methods. When executing an action, the state is updated (in a superficially immutable way, yet actually mutable) and then triggers a rerender in all reactive contexts, including the JSX templates.

Both methods ensure the state is never stale.

Is the functional programming style purely a personal taste when specifically compared against the Reactive programming Mobx uses or does it actually provide better protection against bugs? Readability is of course a consideration as well, but that can be considered a personal preference.

[ryansolid]

For global state, people tend to enforce these patterns anyway. As you mention MobX has actions. So you have people already developing with best practices in mind here. While Solid doesn't have decorator syntax, MobX newer makeObservable API has a lot of similarities to createState other than Solid hasn't really focused on upgrading existing class objects.

These are a little different as once you are in actions any observable can be updated. It's like I'm turning it off across the board for this small synchronous execution, but as you note you just wrap the specific actions yourself and you've effectively created this read-write segregation.. Stores are typically imported as a single object with actions top level and some amount of state that you can't mutate outside of them. So it's mostly superficial the difference between:

const store = userMobXStore();
const value = store.list[0].value;
store.addToList(newItems)
// and

const [state, { addToList }] = useSolidStore();
const value = state.list[0].value;
addToList(newItems);

However, once you start passing things through props and component hierarchy there is a different story. A store is going mostly be fairly lenient with its access to data and actions since it doesn't know how it's going to be used. Luckily it's really clear where it's coming from as you import it from that location. But props.. where do props come from? And what guarantee do you have with what your children do with them?

Now if you are going to define actions every time you pass observables down through props and keep things strict mode, you more or less are doing what Solid is doing. And if you really like the mutable form, just use the produce helper. MobX introduces strict mode and actions, and Solid just gives you a different function to effectively do the same. Realizing I'd always be doing this I thought Solid's approach is much simpler and more consistent. There is no mode toggling and you are wrapping in setState or in action it isn't that different.

Solid is MobX in strict mode with one exception. You need to explicitly pass the ability to update particular state. It is possible with actions to update other observables, and children to define their own actions to act on your state without passing that right. That being said at least it's explicit so it would be easy to track down any bugs.

However, if you don't use strict mode (enforce actions) , you could have someone locally assign a part of nested state to a variable somewhere, and then maybe re-assign a nested value and who knows what happens. Random assignment semantics causing the butterfly effect.

We had this problem in our Knockout apps that I was developing years ago. You start passing functions around enough and especially on the signal side having the setter be the same function as the getter, accidental setting, accidental tracking all over the map. Now generally accidental tracking isn't the worst because if you read it you probably depend on it. But accidental setting can be hard to follow.

In any case I'm just starting things from a place where component level authoring can lead to less footguns. Global state I'm less worried about since people are generally pretty good there. I think in general people are less likely to make these sort of mistakes given years of React mentality training. But there is a sort of symmetry to how everything works in Solid.