First of all, you summarized your question beautifully and easy to understand - amazing job.
The way I code has drastically changed depending on how much I understand the full power and optimization methods of React Hooks.
Here is how it ends up after refactoring.
Props -> barely ever use them unless it's sent one level down. This is probably because of the nature of the projects I've been doing recently, but most data is stuffed in redux, and sent to each component directly via useSelector hook(react-redux)
Context -> won't even attempt to use it before debugging becomes as easy as redux.
State -> usually spam like variables depending on the deadline of a project, but eventually gets refactored into useReducer or a useState that pretty much acts like a useReducer.
That's pretty much it. :)
That's really interesting! Especially the insight about the number of levels down which the props are propagated, I can definitely see how that pattern arises as well.
What do you think is the difference in your projects between what state ends up stored in Redux and what makes it into Hooks state?
The one change I would make to your summary is that you are using context I would bet internally via useSelector, so I would say instead that you "won't attempt to use context without the debugging capabilities of the redux store." That is a point of view about the relation between Redux and context I hadn't considered and is very interesting as well!
What do you think is the difference in your projects between what state ends up stored in Redux and what makes it into Hooks state?
-> The most recent project I worked extensively on was a React-redux + Electron + Sqlite Chat app targeted for Windows. In order to reduce server load, previously loaded data was saved to Sqlite and loaded when the app started, new data on initial load was acquired via REST and sent to redux, along with real-time data received via SocketIO. Since data had to be acquired real-time and updated to the main Electron window's redux store, and also sent to other Electron windows via IPC, there was little to no benefit to keeping data in a component's state - it was too versatile and everything affected everything else so frequently.
In hindsight, an MVVM project structure would have reduced a lot of hassle but we all know that switching project structure is close to impossible when you're barely able to add features on time.
So to answer the question, I'd say there are so many factors that could possibly affect where you store the data, but then again I would consider a chat application as a rather rare edge case.
In most websites, I'd say using redux the least possible is the best-case scenario.
you are using context I would bet internally via useSelector
-> I agree, I was pointing out that the Context API itself currently cannot compete against Redux's extensive debugging capabilities, in the functional sense, those two are virtually the same in most aspects. I believe there are quite a few posts on dev.to on the subject that point this out.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First of all, you summarized your question beautifully and easy to understand - amazing job.
The way I code has drastically changed depending on how much I understand the full power and optimization methods of React Hooks.
Here is how it ends up after refactoring.
Props -> barely ever use them unless it's sent one level down. This is probably because of the nature of the projects I've been doing recently, but most data is stuffed in redux, and sent to each component directly via useSelector hook(react-redux)
Context -> won't even attempt to use it before debugging becomes as easy as redux.
State -> usually spam like variables depending on the deadline of a project, but eventually gets refactored into useReducer or a useState that pretty much acts like a useReducer.
That's pretty much it. :)
That's really interesting! Especially the insight about the number of levels down which the props are propagated, I can definitely see how that pattern arises as well.
What do you think is the difference in your projects between what state ends up stored in Redux and what makes it into Hooks state?
The one change I would make to your summary is that you are using context I would bet internally via
useSelector, so I would say instead that you "won't attempt to use context without the debugging capabilities of the redux store." That is a point of view about the relation between Redux and context I hadn't considered and is very interesting as well!What do you think is the difference in your projects between what state ends up stored in Redux and what makes it into Hooks state?-> The most recent project I worked extensively on was a React-redux + Electron + Sqlite Chat app targeted for Windows. In order to reduce server load, previously loaded data was saved to Sqlite and loaded when the app started, new data on initial load was acquired via REST and sent to redux, along with real-time data received via SocketIO. Since data had to be acquired real-time and updated to the main Electron window's redux store, and also sent to other Electron windows via IPC, there was little to no benefit to keeping data in a component's state - it was too versatile and everything affected everything else so frequently.
In hindsight, an MVVM project structure would have reduced a lot of hassle but we all know that switching project structure is close to impossible when you're barely able to add features on time.
So to answer the question, I'd say there are so many factors that could possibly affect where you store the data, but then again I would consider a chat application as a rather rare edge case.
In most websites, I'd say using redux the least possible is the best-case scenario.
you are using context I would bet internally via useSelector-> I agree, I was pointing out that the Context API itself currently cannot compete against Redux's extensive debugging capabilities, in the functional sense, those two are virtually the same in most aspects. I believe there are quite a few posts on dev.to on the subject that point this out.