A Visual Guide to State in React(daveceddia.com)
daveceddia.com
A Visual Guide to State in React
https://daveceddia.com/visual-guide-to-state-in-react/
4 comments
> This object describes the entire state of this app. And that, in a nutshell, is what React’s state is for.
Isn't that still confusing? When someone says React state, I think component state. React state is usually reserved for UI interaction state.
In the example, let's assume the source of data is from an IoT service. Fetching data would be be pushed/pulled then the application state updated outside of the components. Application state changes then propagate down to components (PowerUsage, IndoorTemp, OutdoorTemp) as React properties not React State.
Isn't that still confusing? When someone says React state, I think component state. React state is usually reserved for UI interaction state.
In the example, let's assume the source of data is from an IoT service. Fetching data would be be pushed/pulled then the application state updated outside of the components. Application state changes then propagate down to components (PowerUsage, IndoorTemp, OutdoorTemp) as React properties not React State.
State in React isn't exclusively reserved for UI interaction state like modals and dropdowns. It's also common to store server data in there if it should persist between renders (which it usually should).
As another example, imagine that a chat app is receiving messages from a websocket. Each time it receives a message it should re-render the list of messages. The "current list of messages" is state. Each received message gets pushed onto an array inside state, which triggers a re-render.
That's not really "UI interaction state" in the sense that the user triggered it, but it's definitely state the UI needs to track unless it wants to fetch the entire list of messages every time a new one arrives.
As another example, imagine that a chat app is receiving messages from a websocket. Each time it receives a message it should re-render the list of messages. The "current list of messages" is state. Each received message gets pushed onto an array inside state, which triggers a re-render.
That's not really "UI interaction state" in the sense that the user triggered it, but it's definitely state the UI needs to track unless it wants to fetch the entire list of messages every time a new one arrives.
I don't have experience using websockets with React, but right now I handle absolutely everything that comes from the server by putting it into app state. Is there a reason for changing that paradigm in the chat example?
Redux and state in an app with multiple components is given one or two sentences at the end.
Discussing where to apply state (to containers?) Is given one or two vague sentences at the end.
Meh... ...disappointed. The writer ia just rehashing the same content from other articles. Albeit somewhat less vague.