Imagine I have a number of entries(say, users) in my database. I also have two routes, one for list, other for detail(where you can edit the entry). Now I'm struggling with how to approach the data structure.
I'm thinking of two approaches and a kinda combination of both.
/list
, all of my users are downloaded from api a stored in redux store, under the key users
, I also add some sort of users_offset
and users_limit
to render only part of the of the list/detail/<id>
, and store currently_selected_user
with <id>
as the val... which means I will be able to get my user's data with something like this users.find(res => res.id === currently_selected_user)
Now the problem I have with this approach is that, when the list of users gets huge(say millions), it might take a while to download. And also, when I navigate directly to /detail/<id>
, I won't yet have all of my users downloaded, so to get data for just the one I need, I'm gonna have to first download the whole thing. Millions of users just to edit one.
/list
, and instead of downloading all of my users from api, I only download a couple of them, depending on what my users_per_page
and users_current_page
would be set to, and I'd probably store the data as users_currently_visible
/detail/<id>
, store currently_selected_user
with <id>
as the val...and instead of searching through users_currently_visible
I simply download user's data from api.. users_currently_visible
in any wayWhat I see as possible problem here is that I'm gonna have to, upon visiting /list
, download data from api again, because it might not be in sync with what's in the database, I also might be unnecessarily downloading users data in detail, because they might be incidentally already inside my users_currently_visible
users_currently_visible
users_currently_visible
if so, I also update that list, if not I do nothingThis would probably work, but doesn't really feel like it's the proper way. I would also probably still need to download fresh list of users_currently_visible
upon visiting /list
, because I might have added a new one..
Is there any fan favorite way of doing this?... I'm sure every single one redux user must have encountered the same things.
Thanks!
Please consult “real world” example from Redux repo.
It shows the solution to exactly this problem.
Your state shape should look like this:
{ entities: { users: { 1: { id: 1, name: 'Dan' }, 42: { id: 42, name: 'Mary' } } }, visibleUsers: { ids: [1, 42], isFetching: false, offset: 0 } }
Note I’m storing entities
(ID -> Object maps) and visibleUsers
(description of currently visible users with pagination state and IDs) separately.
This seems similar to your “Shared data set” approach. However I don’t think the drawbacks you list are real problems inherent to this approach. Let’s take a look at them.
Now the problem I have with this approach is that when then list of users gets huge(say millions), it might take a while to download
You don’t need to download all of them! Merging all downloaded entities to entities
doesn’t mean you should query all of them. The entities
should contain all entities that have been downloaded so far—not all entities in the world. Instead, you’d only download those you’re currently showing according to the pagination information.
when I navigate directly to /detail/, I wouldn't yet have all of my users downloaded, so to get data for just the one, I'm gonna have to download them all. Millions of users just to edit one.
No, you’d request just one of them. The response action would fire, and reducer responsible for entities
would merge this single entity into the existing state. Just because state.entities.users
may contain more than one user doesn’t mean you need to download all of them. Think of entities
as of a cache that doesn’t have to be filled.
Finally, I will direct you again to the “real world” example from Redux repo. It shows exactly how to write a reducer for pagination information and entity cache, and how to normalize JSON in your API responses with normalizr
so that it’s easy for reducers to extract information from server actions in a uniform way.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With