If you use Redux and have a product like Instagram for example (subscriptions, subscribers and the current user for the users state), is it better to design the state using only users as entity without any separation (like a users database table) or should you divide the state shape into blocks like subscriptions part, subscribers part and current_user part?
Thank you very much in advance!
----------------------------------------Edit-------------------------------
https://i.sstatic.net/1zK1T.jpg
Thank's for the replies ! I have the kind of state shown in the picture. The thing is, that's great when you have to update the state but there is a performance issue since we have to perform a loop when we want to retrieve the subscriptions or the subscribers When we go for a divided state and have subscriptions, subscribers and current_user parts, we won't have that performance issue anymore since there won't need any loop anymore But we will have some problems when we want to perform some kinds of updates Like, what when a subscriber just unfollowed the user? We would try and figure out a solution to catch it in order for the store to update the subscribers list. That's a tough task though Because for someone who has millions of followers, that's like keeping track of all of them in the long-polling tech By the way, I'm not using Redux, I'm using my own variant of Flux with a Redux-style state for the stores.
--------------------------Edit2--------------------------
Thank's, guys. I finally did this: https://i.sstatic.net/gzRJs.jpg I now have subscribers and other_users stores too.
There is no right answer for this. However you can have something like below.
{
subscriptions:{/*....*/} ,
subscribers:{/*....*/} ,
currentUser{/*....*/} ,
}
The main thing to keep in mind is keep your Redux state normalized, you can use a library like normalizr for that.
As Array of Objects in Redux State are a bad design, it should be made as flat as possible.
Read this chat for further explanation //groups.google.com/forum/#!topic/reactjs/jbh50-GJxpg
example: if your subscribers is array of objects
{subscribers :[{id:subscriberId1, ....}, {id:subscriberId2, ....}]}
convert this to something like below.
subscribers :{
subscriberEntities:{
subscriberId1:{id:subscriberID1, ....},
subscriberId2:{id:subscriberId2, ....}
}
subscriberEntitiesOrder:[subscriberId1,subscriberId2]
So here if you have id you can directly get it's object from subscriberEntities[id] and also it's index subscriberEntitiesOrder.indexOf(id) without having to loop over each time. :)
Main Benefits of this as explained in Redux docs are:
When a piece of data is duplicated in several places, it becomes harder to make sure that it is updated appropriately.
Nested data means that the corresponding reducer logic has to be more nested and therefore more complex. In particular, trying to update a deeply nested field can become very ugly very fast.
Since immutable data updates require all ancestors in the state tree to be copied and updated as well, and new object references will cause connected UI components to re-render, an update to a deeply nested data object could force totally unrelated UI components to re-render even if the data they're displaying hasn't actually changed.
Because of this, the recommended approach to managing relational or nested data in a Redux store is to treat a portion of your store as if it were a database, and keep that data in a normalized form.