- If every click or letter typed becomes a Redux action, then it can actually slow your app down.
- Using the right directory structure for your app makes imports easier to understand and modify later on.
- Choose the right directory structure for your app
- Redux is a technology that you can gradually phase into your React app.
- Once you get the hang of it, you can use Redux for new features you implement, as well as slowly optimizing your app to get the most out of Redux.
When I first arrived at Agolo a year ago, I was handed a codebase developed entirely in Meteor 1.0. Meteor then (and now) defaulted to…
@meteorjs: Our #Redux Migration (and 5 tips for adoption in a mature codebase) by @tomgoldenberg #reactjs
When I first arrived at Agolo a year ago, I was handed a codebase developed entirely in Meteor 1.0. Meteor then (and now) defaulted to Blaze as a rendering engine, with some pros and cons. One of the first things I advocated for was migrating the front-end code to React.
The migration from Blaze to React took some time (2–3 weeks), but was worth it. It gave me a chance to get my hands on the entire codebase and rewrite parts that were confusing and under-documented. Many months later, when our client-side application state became more complex, I explored Redux as a possible solution and pitched its advantages to my team.
Although I was given the go-ahead to refactor our application state in Redux, I struggled with the task at the time. It has taken experience to realize some of my mistakes in structuring the code and data flow. So, I’d like to share some lessons learned from the experience in the hope that it may save time for other developers :).
There are several approaches to structuring your code, which can make things confusing for a beginner. In a simple Redux example, the directory structure might look like this:
Because of these examples, you might be tempted to put all actions in the actions folder, all components in the components folder, and so on. This quickly becomes a big mess in a complex app.
Instead, a structure like this reads a lot easier:
By doing this, you get nice references like:
import * as actions from ‘../actions’;
instead of this:
import * as actions from ‘../../splash/actions’;
A big part of writing good code is readability. Using the right directory structure for your app makes imports easier to understand and modify later on.
2. Remember: You don’t always need to Redux
Observe the following tweet by Dan Abramov, creator of Redux:
When you first learn about Redux (or Flux), the idea of a single source of truth for application state sounds like brilliant, novel idea. This can easily make one over-zealous, forcing one to convert every piece of state into a Redux reducer. However, this doesn’t make for very scaleable apps. If every click or letter typed becomes a Redux action, then it can actually slow your app down. First decide what state should be shared across views, and then use Redux for that. Other state that only affects a single view might be better off in a localized state. Find the right balance for your application, but remember that all good things can be taken too far.
3. Use descriptive names for action types
Again, in the simple examples, you’ll often find action types such as this:
export const UPDATE_USER = ‘UPDATE_USER’;
export const SET_POSTS = ‘SET_POSTS’;
It helps to be more descriptive, linking each action type with a particular view:
export const UPDATE_USER = ‘accounts/UPDATE_USER’;
export const SET_POSTS = ‘posts/SET_POSTS’;
This makes for more readable logs, which can make debugging less painful.
4. Learn properly before refactoring your codebase
By now, there are a plethora of resources for getting started with Redux. This can be good and bad, because you might not know where to start. Here is what I would recommend as steps to take before introducing Redux to your company.
5. Have a plan and pitch the business value
As a programmer, it’s easy to fall into the trap of pitching an idea solely on its technical merits. Often, you will need to get the green light from someone who wants to know the business value of the proposal. In the case of Redux, I highlighted how it would make debugging much easier and our app easier to extend in the future. I also used my free time out of work to give a simple prototype of how our company app would look with Redux, and a realistic estimate on how long it would take to bring the changes to the entire app.
In any organization, incremental changes are always easier to get approval for than radical, ground-up ones. Luckily, Redux is a technology that you can gradually phase into your React app. Just pick an aspect of your application state that is heavily shared across components and focus on bringing that into a Redux store. A good place to start is user account data, since this is usually shared across your application. Once you get the hang of it, you can use Redux for new features you implement, as well as slowly optimizing your app to get the most out of Redux.