I think the fact that you’re storing UI-specific data (even if it is just IDs) in Redux, is a sign that it is the wrong tool.
In my own app, I store a variety of data in the Redux store: data fetched from the server, UI state like modals/context menus/tabs, app control state like "current selected item", etc. Certainly not all UI state _needs_ to go into Redux, but there's nothing wrong with storing UI state in Redux. Totally depends on where and how it's needed.
If the state is likely to be a common concern, or referenced in another component, them redux it up. If the rest of the app doesn't know/care then scope that state.
If you're using Provider or subscribe() you're going to end up hammering lifecycle methods unnecessarily in relatively trivial UI changes. Just seems unnecessary.
> Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
> Some common rules of thumb for determining what kind of data should be put into Redux:
> - Do other parts of the application care about this data?
> - Do you need to be able to create further derived data based on this original data?
> - Is the same data being used to drive multiple components?
> - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
> - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
As a super simple example, if you had a list of continents, and each continent could be expanded (to list every country inside of it) or collapsed, your Redux state might look like:
{
'continents': [
'Asia': {
'collapsed': false,
'countries': [
'Mongolia',
'Japan',
// ...
],
},
'North American': {
'collapsed': true,
'countries': [
'Canada',
'Mexico',
// ...
],
},
],
}
In what case would you need to generate a random ID per component simply to "remember" where the data for each component is located in Redux?
Yes, generally something like expanding an accordion component can just sit in the local component state, as long as the collapsed state doesn’t need to affect or be affected by other app state.
{
'<randomId>':
{
Asia:
{
collapsed: true
}
}
}
Probably the ContinentsList component would somehow look like this:
<ContinentsList
continents={<continents data>}
renderItem={({ collapse, isCollapsed, continent }) => {
return <ContinentItem onCollapseClick={collapse} isCollapsed={isCollapsed} continent={continent} />
}}
/>