What do explicit mutation and static mental model mean?

Question

In this article https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e34a51e1a I read the quote "React’s true strengths: composition, unidirectional data flow, freedom from DSLs, explicit mutation and static mental model." at the very end.

What do explicit mutation and static mental model mean?

Thanks!

Answer 1

Explicit mutation - This concerns how a react component is ideally expressed as or likened to a pure function, ie given a specific input (in this case set of props), you will always get the same output (in this case rendered DOM) no matter how many times you try with the same props.

As such, any mutation applied to the component or its data should be done with explicit intention to do so within the confines of the component (which is where internal state comes in, usually as a reaction to a change in input props, or by some user interaction within the component) and by doing so that too is reliable and repeatable - given the same props, and the same user interactions, the outcome should still be totally predictable

For this reason React is especially good at being teamed with immutable data structures as props, which aid in reaching this goal (and in doing so react can make some assumptions about when your input changes, in order to provide performance gains)

Also in behaving this way, unrepeatable edge case bugs are dramatically reduced, and bugs still present can be much more easily reasoned about and tend to be localised to the component or its direct inputs

Static mental model - When writing your application view layer with React, you can easily distill your thinking to just the component at hand, it could be removed from the context of your application entirely and still make sense. You just need to think that given some particular input, how should this particular component look and behave.

For example, given a Todo list, you would not need to remember that in another part of your application pressing a Complete All Tasks button changes a classname each todo list item node to show that it is complete, and that it removes event listeners that allow you to complete them when clicked (ie remember which other parts of your app mutate the DOM you are working with)

It can simply be modelled in isolation as a <TodoListItem complete={true} /> component. If its true, then can show itself as complete by setting its own className and can manage its own event handler based on whether complete or not. It is in essence a black box, that nothing else needs to know how it gets shown as complete or how it behaves when it is complete. Ie pressing a button would just pass it complete={true} and be done.

Its much easier for your brain to concentrate on just the single component, what would make sensible inputs, and how it should behave, than have to also be thinking about if anything else in the application will also be adding a completed classname to the same node and manifesting as a bug right?!

Equally importantly, it makes it easy to test, and extremely easy for someone else to come along, take one look at you component and understand it, and confidently work with it as they know it can be treated in isolation. What they see is what they get. Even to the extent that a CSS/HTML expert without domain knowledge of the application, React, or even javascript itself, could change the look of it with new classNames and markup, and be confident in their change working in the context of the application (perhaps by using a static tool such as https://storybook.js.org/ which is a perfect example of this point being used to great effect)