Re:Why is setState asynchronous?
by tmppdi9876 on Thursday January 25, 2018 @01:25PM
(#16233166)
What i like to do is to write every component as a stateless component. This way you can write a wrapper component that handles local state, lifecycle methods etc and just pass the needed functions and variables to the dumb component or you can switch to redux. The component doesn't care it just needs to have the state altering functions as parameters and the updated state. The problem i see is when new developers start writing a huge class that is coupled with the state handling and calling this all over the place.
I use withState from recompose heavily for this reason.
That’s what I do. Even if you’ll likely never use the stateless component directly in an app, it makes automated testing and things like Storybook much simpler.
I've certainly seen a number of people in the community who insist that you _must_ keep everything in Redux, and that you should probably only use functional components along with that. I can understand why people might want to do that, as it means there's more state in the Redux store for traceability, UI output becomes highly predictable, etc. However, I would say that approach is too dogmatic and over-opinionated. It's a valid choice if you want to go there, but not something that should be enforced across the ecosystem or taught to learners. Class components, functional components, Redux store state, and React component state are all tools with specific use cases, and throwing any of them away is unnecessarily limiting your toolbox.
(Might not have been exactly what you were asking, but given how frequently this topic comes up, I wanted to put that clarification out there.)