Good strategy for reducers in react + redux?

Question

I am using React + Redux to build a webapp talking to an API, similar to what is shown as an example in https://github.com/reactjs/redux/tree/master/examples/real-world .

My API returns artists, albums and tracks list, and allows to query a list of them or an individual artist, album or track. (Think of it as /albums, /artists and /tracks, with additional /album/:id, /artist/:id and /tracks/:id).

I implemented an API middleware and used a paginate reducer as in the example above to get a store with paginated keys for albums, artists and songs retrieval.

Now, I'd like to implement the singular calls to get a single object and display it. But I am not sure about the correct way to handle my reducers. Should I just combineReducers with extra reducers artist , album and track to manage and store these items?

Another question I have related to reducers management is that with my current setup, I store 3 paginate reducers, each containing 30 items. That is I have almost 100 items in my store, while at most 30 of them are displayed at the same time, which seems to not be very efficient. Am I doing it right?

I looked for real world open-source examples with a quite large API behind, but could not come across examples a bit more elaborated than the real world example above :/

Thanks!

Answer 1

Apparently, there is no one rule fits all in React.

However what I've noticed in most boilerplates and react web apps on GitHub is that a reducer is generally created for each container.

So yes creating reducers for your artists, albums and track would be a good practice, you can then combine them into one rootReducer using combineReducer; here is an example.

import { combineReducers } from 'redux';
import artists from './artistsReducer';
import albums from './albumsReducer';
import tracks from './tracksReducer';

const rootReducer = combineReducers({
  artists,
  albums,
  tracks
});

export default rootReducer;

Again this information is from self-experience and watching repos using react - redux, please do correct me if I am wrong.

Best Regards,

Answer 2

I've started keeping the state quite segmented by domain object type - so artists albums and tracks (as well as some user interface state like "overlay", "error messages" and stuff like that). Then I have some reselect classes that take the current state and process it into something usable by my React components.

That gives me a simple data store (which is testable with your favourite unit testing framework) separate from data transformation (which is independently testable).

The good thing about reselect is that it provides a nice data transformation pipeline and it caches the results - so that you don't always need to recompute the data transformation. Which means your React components can be better about when they don't need to re-render.

Oh, and on the efficiency side of things with storing lots of cached data from the server. My strategy is to cache aggressively - so I don't purge stuff from the cache. However, I have a separate object called a "controller" that monitors the redux model and triggers events based on state changes (like pre-loading data). This is where I'd put cache invalidation code if it ever became a performance issue. Or you could get the reducer to do the cache invalidation.