> They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM.
This doc is generally on point and a very important lesson to drill into the heads of people new to react, however that particular phrase is completely misleading. React is absolutely pushing you to use lifecycle effects where necessary. Calling that "stepping outside" is just dishonest.
React is not a "pure view library" that you have to integrate with state management. It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.
> route change, component "mounting", data fetching...
This should really be:
route change -> data fetching -> rendering
After the data is fetched, it should just be assigned to a state somewhere, and the React should, well, "react" to the state change. This may seem a bit complicated for simple cases, but keeps the execution flow explicit and "steppable" though the debugger.
We use MobX for the "react" part; I'm sure this is not the only way.
Yes, but that is The Elm Architecture. React's docs guide you towards using react-query and react-router, making everything lifecycle bound and the renders impure.
> Calling that "stepping outside" is just dishonest.
I don’t think it’s dishonest. There’s two main phases in react, render and commit.
Render is interruptible. For example when a new event like an interaction comes in, the in progress render might get chucked out and restarted with the new information.
Commit isn’t interruptible. It’s a sync phase. This is where all the effects run, and the purpose is to take the new state from the render phase and synchronise it to the external systems. Aka cause side effects.
The useEffect hook running in the commit phase, does let you step outside of the react framework. It lets you safely interact with external systems. If you tried to do any of that in the render phase, you risk getting cut off halfway, or doing things out of order.
> React is not a "pure view library" that you have to integrate with state management.
A view library without state management would be a templating engine right?
> It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.
It lets you define how to respond to those changes in the render phase, but they aren’t applied until the commit phase.
And that means you can wrap up the complexity in well tested components that provide a simple API.
This doc is generally on point and a very important lesson to drill into the heads of people new to react, however that particular phrase is completely misleading. React is absolutely pushing you to use lifecycle effects where necessary. Calling that "stepping outside" is just dishonest.
React is not a "pure view library" that you have to integrate with state management. It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.