Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One question I have for you: In those large React apps, did you put all state changes in the big single central app state data structure?

I'm currently building an app where the core state is simply a tree of plain old mutable JS objects. We have all the expected disadvantages (mostly: no easy shouldComponentUpdate), but things are easy to reason about, otherwise. We found that stuff like "has the user expanded a dropdown" or "which auto-completeable search term has just been entered" works perfectly in a local component's setState. The idea is, basically, anything that the user doesn't care losing when navigating away from the current screen can go in a local component's state. This seems to go entirely against the functional immutability idea, but it significantly reduces the amount of updates we need to do to our big central data structure.

I'm going to build a new thing and I'm considering going the nice functional way. However, I can't see any downsides to using directly mutable state to simple, local, unimportant stuff.

Would you do it like that? Or would you avoid component state altogether and go with props only?



We also use component local state for things like that, and David Nolen (Om) likes component local state too. But the state goes up top by default. The biggest reason for this is because you might want to attach a diagnostic component to your state (e.g. a json editor [1]), and you don't want to have to change the shape of your state to do that.

[1] https://github.com/dustingetz/react-json-editor




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: