use logic to update component state about redux-logic HOT 4 CLOSED

Yeah, I believe you are right in that it is somewhat of an anti-pattern to go that route.

In general we are trying to move towards one global store for the majority of our state (in Redux), however there are some situations where you can use component state. It just muddies the waters since now you might have to look in multiple places for your state.

If you were to pass in a reference to the component so that you can call setState, that should all work fine assuming the component is still mounted and all. If you are performing async work, then your page might have changed and the component is no longer mounted, so I don't even know what happens if you try to do a setState on an unmounted component. Of course the same could be true in what you have now, so maybe it isn't an issue.

So it seems like this would work (assuming unmounting doesn't cause problems) but in most cases it would seem better to store this state in redux. There is just one place to look for your state that way.

from redux-logic.

So it seems like this would work (assuming unmounting doesn't cause problems) but in most cases it would seem better to store this state in redux. There is just one place to look for your state that way.

This would be my answer. The component I am using is a CrudGenerator components.
I think it requires me to create hundreds of new store that could be handled within the components.

It's not a redux-logic related question then, but If the redux store grow to the infinite, quid of the life performance of the running application?

from redux-logic.

Well the nice thing with redux is that it is easy to split up the state and manage them with different reducers bringing them together with combineReducer. You can even add these on the fly, with split bundle loading where you only add in the reducers based on what parts of the app they navigate to.

As for the performance when you have lots of state in redux, there is actually some great ways to make sure that it can perform well. The biggest one is to simply only connect deeper components with the state they need to use. So in using react-redux connect(), instead of connecting all the state at the top App component, you instead connect deeper components (containers) with just the state it uses. For instance if you have both users and repos in your store. You only connect the users related components with the user part of the store via connect and in the repos components with the repos state via connect.

So this isolates the updates to only the parts of your app that need them. User updates only affect user components and vice versa for repos. Thus performance can be maintained regardless of how complex your app gets, each part only needs to update for the data it cares about.

So segment things in your store so you can selectively hand out what is needed. Use additional reducers as necessary to make it easy to manage. Don't connect full state at the App level, just connect the necessary data deeper in the tree at the component that needs the info, and you'll be able to maintain performance as your state tree and app grows.

Under the covers react-redux connect() is basically implementing shouldComponentUpdate in the connect call, so that's how it can limit updates, but if you need even more tweaking you can also do that inside your deeper components to further adjust. I'd resist doing that until necessary though, usually segmenting state via connect is all you need to do.

from redux-logic.

We already use the combineReducer from the boilerplate and it seems to work fine. But I see the redux store growing on each page change. It's probably just developer tools that give this feeling.
All your explanation make sens, let's see how it goes.

from redux-logic.