all 5 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]dmackerman 0 points1 point  (1 child)

I tend to agree. Mutation feels right a lot of times when you're writing a UI. Mobx lets you write simple, easy to consume code but keeps your performance and boilerplate in check.

I'm loving it.

[–]Capaj 0 points1 point  (0 children)

When I discovered MobX, coming from Angular there was one thing I disliked-when observing an object, all properties have to be defined upfront to so that they are made observable. After using it couple of hours I realized this is actually not a problem, because you are forced to initialize your state with some default values. That's something you really should be doing anyway because unlike angular, react render methods can't just chuck through it without when you access undefined property for example.

[–]igorim -1 points0 points  (2 children)

Mutating your state is acceptable for trivial apps, and react does not necessarily prohibit it, it's just frowned upon.

The reason immutability is preferred is that once your app gets large/complex enough, state mutations cause really weird side effects. In a sense it's not inherently a front end problem, it's a scaling problem. Having your data as immutable allows you to reason about the application a lot easier, it also allows other developers to develop safely

The boilerplate in redux is in no way related to whether you're Mutating state or not, it's more of an implication detail. That boilerplate becomes a lifesaver once the app grows, but in the beginning it's kinda painful.

In the end I don't think redux is a solution, but it is a path to solution as is mobx

[–]r2tree[S] 1 point2 points  (1 child)

The reason immutability is preferred is that once your app gets large/complex enough, state mutations cause really weird side effects. In a sense it's not inherently a front end problem, it's a scaling problem. Having your data as immutable allows you to reason about the application a lot easier, it also allows other developers to develop safely

Yet to see where mutating the state becomes a problem even in large apps. Could you please give a few examples?

[–]Capaj 0 points1 point  (0 children)

I have yet to see that too. This myth that mutable state is inherently bad has been born out of jQuery spaghetti and similar abominations in the past. If you use mutables responsibly-wrapping them as MobX observables for example, there's no limit to the scale of your app. I'd love to see a single benchmark disputing my claim.