So I guess in your comment you do mean that context causes everything to be re-rendered (if App uses one context and store all data in it for the app)... and even if we split the context into 2, it could still cause half of the components to re-render (unnecessarily).
And so Redux is better... it only causes any component that is "connected" to be re-rendered? (I am still reading up more on Redux).
All components using a context will rerender if the context changes. So you should not use one big shared context but only store related information in the same context (e.g. theme, auth, used language; these are common use cases).
Also you don't want to use context if it's state changes frequently (e.g. inputs, some frequently calculated values...).
I only use redux if there is some global state which can change frequently. Otherwise I prefer the context API + hooks.
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.
So I guess in your comment you do mean that context causes everything to be re-rendered (if App uses one context and store all data in it for the app)... and even if we split the context into 2, it could still cause half of the components to re-render (unnecessarily).
And so Redux is better... it only causes any component that is "connected" to be re-rendered? (I am still reading up more on Redux).
As far as I know:
All components using a context will rerender if the context changes. So you should not use one big shared context but only store related information in the same context (e.g. theme, auth, used language; these are common use cases).
Also you don't want to use context if it's state changes frequently (e.g. inputs, some frequently calculated values...).
I only use redux if there is some global state which can change frequently. Otherwise I prefer the context API + hooks.