How to structure your react app.

Written by ven_korolev | Published 2018/04/23
Tech Story Tags: javascript | react | react-native | redux

TLDRvia the TL;DR App

When you work in a big team it is always good to have one style guide not only for CSS & JS but also for structuring components and folders. I decided to write my own to show how and where I put my files and folders. Let’s start!

Link to the second part.

I always divide my components by business value. I call it bundle .

For example, every application I have ever built has a common bundle, which keeps all common components, like Header, Footer, Button, Modal and etc. If you have a user page(settings, photos, profile) it would be a user bundle which would have all the components specific to a user. It’s really handy to have a structure like this because whenever you see a page in a browser you can always say where you need to go to find that component. It is also good for newcomers who don’t really know how you structure your components. They would be able to guess what bundle it is. For example: /user/22/preview the page would show a component from user bundle. It’s easy to guess.

Every bundle has a few folders:

  1. **actionCreators** hold redux-actions.

2. **Components** is a folder for all the components for a bundle. Every folder in components folder should be named with a first capital letter as all components’ files. The reason why I always use first capital letter because when you search for a file by name in your project you can always recognise components just by name header vs Header , you always know that the second one is a component. Before you start reading further, please consider reading this article.

Now let’s talk why there are three files instead of one.

Header.js is just a plain view. It might be a stateless component(function) or a class. I prefer to use a class because classes work with HMR out of the box but it’s up to you. The only thing you should know is that view is a dumb component which only must render props and no business logic should be there.

HeaderContainer.js is a “smart” component. This kind of components always does data fetching, preparing data, getting data from redux-store/relay, define actions, injecting intl or jss. It is a good place to compose higher order components. Usually, you don’t import react inside smart components because you should not render anything there. This is how it should look like:

index.js just re-exports components. If you import your components somewhere in your app you would do it like this import Header from 'bundles/common/components/Header/Header.js’ . To avoid double Header/Header.js we can re-export our Header component inside index.js. It’s also good to have it here because you might have two containers and only one view, for example: CreateUserFormContainer.js UpdateUserFormContainer.js and only one view UserForm.js . And of course you have two different routes: update-user & create-user .

Now we can import our components just like import { Header, HeaderContainer } from 'bundles/common/components/Header';

3. **reducers** is a folder for all the reducers for a bundle. Reducer for intl.js would look like this:

4. **routes** folder keeps all the routes for the current bundle. You can have a few routes files for the same bundle. For common bundle, it’s not normal to have any routes because it’s common bundle, but let’s say we have one route which displays our Header: /header .

I collect all the routes in every route’s file and export them as an array. Later in my entry point of the app, I import all the routes, merge them into one array and render inside Router .

Conclusion. The only thing which matters is how comfortable you are and your team working with each other. The style guide is just a convention which you and your team define. Hope you enjoyed this article. Please like & share if you like it. Peace.

Link to the second part.


Published by HackerNoon on 2018/04/23