Scaling Redux applications with Reducks
By: Rohan Dhar
Tags: Scalability, React, Modular, Scale, Redux

Scalability is a huge concern for any application. It comes with a unique set of challenges. Same goes for apps with redux implementation for state management.

As such, choosing the correct design patterns and keeping the modules as decoupled as possible becomes very important. Traditionally, two standard approaches have been followed to structure Redux projects, and they are the Function-first approach and the Feature-first approach.

Let’s look into these structures a bit before diving further into scalability concerns.

Function-first approach: In this approach, the top level directories are named after the purpose of the function of the files inside. So, generally one tends to name the directories as reducers, actions, selectors, sagas, etc.

This approach does not scale at all. As the application grows and more features are added, the structure gets messed up and ends up hampering the productivity of developers due to a lot of context switching during development.

Additionally, the files are coupled and hence a single flow through the application will require files from all folders. However, one advantage of this approach is that it allows keeping React files separated from Redux.

Feature-first approach: Feature first approach involves naming the top-level directories after the features of the application.

This approach scales better as each feature is separated into a different folder. However, there is no separation between React and Redux. Changing one of them, in the long run, can be a tricky job.

Additionally, there can be files that do not belong to any feature. They end up in a common/shared folder as they are likely to be used in multiple features in the app.

So, now comes the most important question about scalability. The question is how can we scale an application using the best of the two worlds. Thankfully, the re-ducks structure comes to our rescue.

So, what is re-ducks?

Re-ducks is a redux modular architecture introduced by Alex Moldovan as an extension to the ducks modular approach by Erik Rasmussen.

It is a practice of organizing the state of an application in a way that it scales. First of all, all the UI (React) files should be separated from the Redux files.

The UI files should be kept in a folder named Views ideally. It is ideal to follow a function-first approach in the context of React: layout, pages, components, enhancers, etc. To scale better, feature-based segregation could be followed within the folders.

After properly structuring all the React files, it is time to organize the redux files. The following steps lay out the steps to do so.

All the state files should be kept in a top-level directory named state.

The state directory should have the following structure:

Ducks — contains all the duck folders. A duck folder is a domain level state, such as user, cart, etc. A duck folder contains all files related to a particular domain level state.

The Ducks folder contains an index.js file and all the domain-level state folders.

State/Duck folder- this is named after the name of the state. It contains the following files:

index- exports the state reducer as the default export. Actions, selectors, types, and operations are exported as named exports. types- Contains all the action types related to a particular state. actions- Contains all the action logic related to a particular state. reducers- All the reducer logic is bundled in this file. selectors- Contains selector logic operations- All the middleware logic is kept in operations. You may name it saga, epic, thunk depending on the use case tests — Contains all the tests related to a particular state.

After organizing the Ducks folder, proper attention should be paid to organizing the middleware and store configuration files. Personally, I love to keep these files/folders within the state folder as this ensures as the state configurations and logic are in one place.

How it all started?

The need for scalability led to the ducks modular approach. In ducks, all the code associated with one state (action creators, reducers, selectors, etc) is kept in one file. This allowed scaling redux apps with ease but keeping all the associated code in one file clutters it in the long run.

Thus, the re-ducks pattern evolved. Re-ducks implements organizing code following ducks principles, but instead of keeping every associated with a state in one file, it is organized in one folder. This allows for better code organization, management, readability, and scalability in the long run.

Way forward

The best feature of re-ducks is that it implements a consistent pattern for structuring all redux code. The feature-based split works well for scaling Redux code, while the function-based split for React code works brilliantly for small, shareable components.

The way forward from here would be to try out re-ducks in a redux project and see its impact on scalability.

You may consider reading the following materials before starting with re-ducks hands on.

Further Readings:

Re-ducks Repo:

https://github.com/alexnm/re-ducks

Scaling Redux apps:

https://www.freecodecamp.org/news/scaling-your-redux-app-with-ducks-6115955638be/

Learning Redux with Re-ducks:

https://www.aaron-powell.com/posts/2016-06-06-learning-redux-with-reducks-intro/