Planning Your React/Redux App's Architecture

[viphat]

Trust us, planning out your project before starting to code will save you a lot of time later on.

Many developers make the mistake of starting to code before they've put any thought into figuring out precisely what their app's architecture should be. This approach results in spending an incredible amount of time debugging, restructuring the code, and sometimes even starting over, completely!

Planning Your React/Redux App's Architecture

1. Identify What Each View Should Look Like
2. Break Each View Into a Hierarchy of Components
3. Determine What Events Happen in the App
4. Determine What Data Lives in the Store

[viphat]

Step 1 - Identify Each View

We need to determine the look and functionality of each view in your app. One of the best approaches is to draw each view of the app on paper so that you'll have a good idea of what information and data you're planning to have on each page.

Instead of paper and pencil, you can be a bit more digital and use software for creating mockups. If you were given project specifications, check your mock against them to make sure that you have all of the required features.

[viphat]

Step 2: Break Each View Into a Hierarchy of Components

In this step, we'll do 2 things:

• Draw boxes around every component.
• Arrange our components into a hierarchy.

A component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.

Components let you split the UI into independent, reusable chunks. Each view typically has a component that represents that view. Presentational Components don't know where their data comes from. Components that are connected to the store are called 'containers'

Component Hierarchy tells us which components will be used inside of other components. It gives us the skeleton of our app.

Remember that Redux doesn't care about how our app looks or what components it uses. Instead, it gives a way to manage the state of the application in a predictable way. When we talk about state, we're really talking about data - not just any kind of data inside the app, but data that can change based on the events in the app.

[viphat]

Step 3 - Determine what Events happen in the App

We need to take a look at what is happening in each component. Let's determine what actions the app or the user is performing on the data. Is the data being set, modified, or deleted?... Then we'll need an action to keep track of that event.

[viphat]

Step 4 - Determine What Data Lives in the Store

Remember that the main problem that Redux (and the react-redux bindings) was meant to solve were:

• Propagation of props through the entire component tree.
• Ensuring consistency and predictability of the state across the app.

We should follow the following principle for determining whether to store a piece of data in the store or in a React component:

Use Redux for state that matters globally or is mutated in complex ways. The rule of thumb is: do whatever is less awkward.

Take a look at Organizing State and How to choose between Redux's store and React's state? for further information about this.

[viphat]

State Normalization:

• Each type of data gets its own table in the state.
• Each data table should store the individual items in an object, with the IDs of the items as keys and the items themselves as the values.
• Any references to individual items should be done by storing the item's ID. Arrays of IDs should be used to indicate ordering.

tweets: {
  tweetId: {tweetId, authorId, authorName, authorAvatar, timestamp, text, likes, replies, replyingTo},
  tweetId: {tweetId, authorId, authorName, authorAvatar, timestamp, text, likes, replies, replyingTo}
}

{
  tweets: {
    tweetId: { tweetId, authorId, timestamp, text, likes, replies, replyingTo},
    tweetId: { tweetId, authorId, timestamp, text, likes, replies, replyingTo}
  },
  users: {
    userId: {userId, userName, avatar, tweetsArray},
    userId: {userId, userName, avatar, tweetsArray}
  }
}