4 ms·
the whole point of setState is that it forces you to think about component state from a centralized point of view and help avoid modeling it the wrong way (eg a
by nsonha 5y ago
the whole point of setState is that it forces you to think about component state from a centralized point of view and help avoid modeling it the wrong way (eg a bunch of optionals instead of an union type for the whole state). If you split them to a bunch of states then state becomes just mutable var in a different syntax.
- steve_adams_86 5y agoThey’re much different than mutable variables with a different syntax. Changing them causes your component to render and reflect changes.
- nsonha 5y agothat doesn't matter. Look at frameworks in which you have states that when mutated, trigger a rerender, such as svelte. Suddenly (scattered) setState calls are not very different than (scattered) assignment statements
- bayesian_horse 5y agoThat's not really true. Regardless how many setters you have or invoke, state only changes between renders. Of course state is mutable, that's the whole point. It's not mutable during the render function though. It's also easier to accidentally mutate an object assigned to a const than a string or number. Also, the setters are usually passed around all over the place, so no, I don't think the point is centralizing component state at all.
- nsonha 5y agocentralizing as in when you setState({ a: true }), you also think "wait a minute is having a `state.b` still makes sense, now that "a" is `true`", maybe it should be setState({ a: true, b: null }) > It's not mutable during the render function I don't think that's the point at all when people talk about mutability. To me mutability is just a proxy for "lacking access control", which again goes back to the point about centralizing state updates. So arguing about the technicality of what is mutable and what is not is pointless.