Immutable data-structures are useful, but also it is quite a lot of work to transform a codebase written with mutable data-structures into one with immutable ones. This is because mutability is a "viral" property.
It'll depend on the codebase of course, but I think it's a lot less work if you're using the flux frameworks that seem to be popular with modern JS apps.
I think it's interesting that Elm and ClojureScript have chosen immutability as the default. I wonder what other languages have chosen this.
An easy way to structure the code with immutable data is to made it essentially read only. Anything can read the data state and that can be shared throughout an application, but to write, you need an explicit function call or event
I'd go a step further than mentioned... as static render components (single functions) are possible... if you're using something like redux/connect, you can export the static function, along with the default of the connected version. By doing this you have really straight forward testing, and don't even have to deal with the variance of class/object instances. I've build a few apps at this point using only static components.
Also, there are options to use immutable for state with redux (it's a little different), but it can be useful, to say the least.
The only downside of static components is that hot module replacement doesn't seem to work right, there are ways around it, but not as much fun... that said, I tend to save state to sessionStorage on every change, loading from sessionStorage at start, so refreshing the browser will just show the updated rendering.
How does all of the cloning affect performance? It feels wasteful to create these short-lived components that are explicitly discarded for slightly modified ones, but is that actually a problem?
I'm not sure of the exact logic it uses, but it appears to me that when React finds a new component in place of an old one of the same class, it just changes the props on the old component (and calls componentWillReceiveProps) which bypasses some of the lifecycle calls.
Also, I believe Chrome and Firefox (and hopefully other) garbage collectors use a generational algorithm which makes it very cheap to throw away short-lived objects.
Of course it's more efficient just to mutate state, but these factors and other optimizations should mitigate the added cost and I think for most applications, the wasted cycles are not going to be much concern.
Interesting, the examples don't use JSX syntax. I wonder, does this make it easier to work with TypeScript, or do they have some other reasoning for not using JSX?
The article is about writing a simpler system, not strictly using tools to help manage state. Part of making simpler tools involves making things less stateful, yes, but it's a higher order concept that won't be solved by using a particular tool.
MobX is a great alternative if you are enthused about mutable state, and don't want to rewrite your brain to write reducers, immutable data, and deal with functional programming concepts.
I wouldn't say it's addressing these concerns so much as it agrees with some of the same solutions this article suggests (immutability, pure functions) and turns them into requirements. At least until you want asynchronous actions (and you will) in which case it seems to shrug and encourage using addons with side effects.
The standard "react-redux" bindings make use of the presentation/container component pattern described here as well.
I prefer the redux-thunks with async functions, as this lets me be more explicit and do a bit more work, if I need more status levels than loading/success/failure modes. This is a relatively simple example, and pretty close to how the defaults for redux-promise works...
There's no side-effects to having your async calls inside your action creators... Well, there's a chance that an intermediate action may be dispatched in between the loading and success, but even then, unless things are very brittle, it's easy enough to mitigate, and that's only for portions of the tree that are shared.
Okay, it is subject to side effects, since the input from the original method call isn't the only point of intersection/input, the async call is part of it...
Just the same, the exposure is still minimal, and easily testable.
> At least until you want asynchronous actions (and you will) in which case it seems to shrug and encourage using addons with side effects.
Imho there's nothing special with async actions and you don't necessarily need an addon, they're just actions arriving to the reducer later, and it can't see the difference. Your data fetching is no more async than a user clicking on a button.
Note however that it does say "This function doesn’t need to be pure; it is thus allowed to have side effects, including executing asynchronous API calls."
