0

I have a React-Redux app where I have several tabs, and I keep my code in a structure of folder-per-tab. Each folder contains an actions file, service file, constants file and a reducer file.

When I fetch the data from the server, I fetch it as one big nested object, whose top level keys are sectionA, sectionB, sectionC and so on.

Each tab may use data from multiple sections, for example, tab 1 may use sectionA and sectionB, tab 2 may use sectionB and sectionC and so on.

This creates a problem in the way I split the data into reducers. If the top level keys in the redux store will be "tab1" and "tab2", and I would want to update data in sectionB, then I will have to do it in two different reducers. On the other hand, if the top level keys would be "sectionA", "sectionB" etc, then my folder structure is wrong. Any way to solve this?

Thanks.

1 Answer 1

1

It sounds like you are thinking very much like a front-end developer, and categorising your state according to how it relates to the user interface.

You might want to think about how you are normalizing your state shape: https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape

Redux is really a tiny backend for your front-end. I'm sure the purists will debate this on a million levels, but it actually functions like a little, local document store.

Try thinking about your redux structure more in terms of what the data is, than where you want to put it on the screen.

the normalizr library is some next level-ness for that https://github.com/paularmstrong/normalizr

I'm still debating whether I think it's too far. My app is starting to turn from an MVVC into an MVCMVCCVMMV... (you get it, some kind of epic roman numeral).

How much data do I want to keep in a pubsub model locally, vs always hitting my API server for that?

How long does a user leave a page open, filling the redux store up with new data until there's a memory problem?

Garbage collection in redux is a whole extra conversation, and this is worth a read: https://github.com/reduxjs/redux/issues/1824

Old mate Dan Abramov jumps in with some useful thoughts on that thread.

I realise none of this is an answer per-se, but it seems like redux has more 'use case scenarios' than answers generally anyway.

Sign up to request clarification or add additional context in comments.

4 Comments

But what solution do you think fits for my case?
@Mister_L You would have to tell me about the types of data you are storing on your tabs. Is it your own API, or someone else's? Are they small collections, or likely to be large collections of thousands of rows of data? Some of my tabs in my current project have 20 odd rows, others thousands. I have to use a different structure for the paginated sets.
@Mister_L for example my paginated data tables only contain the current page data in the state, and push back to the API for the next state. In some ways, it's overkill and the component state should hold the page data. The redux store could just keep track of what page we were on, and then the app could hit the API for the page data every time. I'm planning on refactoring eventually.
@Mister_L a previous team member decided to add details about the state of the app to the individual rows of the table, for when we are viewing details etc. A disaster I have not yet had a chance to unravel. Lovely guy, terrible solution.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.