5 ms·

Excellent! Love the extended state.

bayesian_horse 5y ago
It's unnecessary. Just use individual useStates for each property. Makes it easier to type, too. Otherwise you might as well go with something like Redux.
- xixixao 5y ago
  Redux is far from the suggestion, and imho unless you can greatly benefit from the actions boilerplate its overhead is not worth it. As others mentioned useImmer is a more bulletproof solution then assuming your state can always be modeled by a single layer Object though.
  - bayesian_horse 5y ago
    I too felt like that for a long time. Eventually I got when and why Redux is useful, even with the boilerplate. Also, modern semantics and utilities greatly help. Redux Toolkit, RTK Query, reselect and so on. Actions make state more debuggable. Selectors make rendering more performant and often help structure complex rendering logic. Also, Redux is a way of not having to define asynchronous control flow by composing components, which can get really messy. Granted, it's not necessary for every app.
    - handrous 5y ago
      I like Redux because it's portable—you can easily rip it out of a React project and use it anywhere—and because it provides a really nice way to separate backend-talking-stuff from frontend-rendering-stuff, if you're dividing up dev tasks. Nice clean place to split off a library for whatever service(s) you're consuming. And with Typescript, it's not a bit unpleasant to work with.
  - 5e92cb50239222b 5y ago
    Redux Toolkit doesn't require much boilerplate anymore (IMHO). I found Redux to be absolutely appalling and never used it (despite having some familiarity with functional programming and the ideas underlying Redux) before RTK came along.
    - acemarke 5y ago
      Heh, glad to hear that RTK is an improvement there :)
- tddhk 5y ago
  Completely agree, also individual named state hooks are great for semantic reasons, they will make your code more readable and more easily maintainable.
- 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 ago
    They’re much different than mutable variables with a different syntax. Changing them causes your component to render and reflect changes.
    - nsonha 5y ago
      that 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 ago
    That'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 ago
      centralizing 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.

It's unnecessary. Just use individual useStates for each property. Makes it easier to type, too. Otherwise you might as well go with something like Redux.

xixixao 5y ago
Redux is far from the suggestion, and imho unless you can greatly benefit from the actions boilerplate its overhead is not worth it. As others mentioned useImmer is a more bulletproof solution then assuming your state can always be modeled by a single layer Object though.
- bayesian_horse 5y ago
  I too felt like that for a long time. Eventually I got when and why Redux is useful, even with the boilerplate. Also, modern semantics and utilities greatly help. Redux Toolkit, RTK Query, reselect and so on. Actions make state more debuggable. Selectors make rendering more performant and often help structure complex rendering logic. Also, Redux is a way of not having to define asynchronous control flow by composing components, which can get really messy. Granted, it's not necessary for every app.
  - handrous 5y ago
    I like Redux because it's portable—you can easily rip it out of a React project and use it anywhere—and because it provides a really nice way to separate backend-talking-stuff from frontend-rendering-stuff, if you're dividing up dev tasks. Nice clean place to split off a library for whatever service(s) you're consuming. And with Typescript, it's not a bit unpleasant to work with.
- 5e92cb50239222b 5y ago
  Redux Toolkit doesn't require much boilerplate anymore (IMHO). I found Redux to be absolutely appalling and never used it (despite having some familiarity with functional programming and the ideas underlying Redux) before RTK came along.
  - acemarke 5y ago
    Heh, glad to hear that RTK is an improvement there :)
tddhk 5y ago
Completely agree, also individual named state hooks are great for semantic reasons, they will make your code more readable and more easily maintainable.
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 ago
  They’re much different than mutable variables with a different syntax. Changing them causes your component to render and reflect changes.
  - nsonha 5y ago
    that 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 ago
  That'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 ago
    centralizing 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.