Component Style Guide

This is a component style guide that tells how to classify components based on their role in the application and when to create a seperate component on that role.

Roles

List of roles that a component can have.

This is the root component of the application. It usually contains the routing system (if you have one) or the main shape of the page and is named App. It is a best practice to seperate your code into an App component and not keep the index.js to creating Redux stores (you can put that in the App component too), registering service workers, rendering the App component, and doing other setup and initialization work.

Route Components

Always seperate a route into a new component. Routing can easily get complicated and having all the components for each route built inside the Route components’ props as a class or a function just makes it more complicated. Even if its a simple page like a 404 or an about page, you should always seperate it into a new component.

Porting Components

Whenever porting a library into your framework, e.g. CodeMirror in ReactJS, put all that logic in a seperate component that takes configuration (if you have any) through props. Even if it’s as simple as adding a spinner which is written in plain CSS, it's best to put that code inside a seperate component and keep your component focused.

Display Components

These components take in data and display it. Display components should be created when there is repetition (i.e. multiple appearances in code or when using multiple times e.g. in Array#map) or complex data manipulation. You shouldn’t extend this way too far and create a component for every section in a static page for example. Try to create a new display component when your current component is being less focused and filled with repetition and/or logic that could be separated.

Utility Components

These components make it simpler to read the code and/or reduce repetition of code. An example could be to create a component called Paragraph that simply returns a p tag but instead with a group of custom classnames instead of copy pasting it everywhere. Another cooler example would be to write a component named Section which would create a heading tag followed by the content specified in the children. When creating utility components, avoid creating multiple with similar logic to simply take data in the name. An example of this would be to write Section1 for h1 followed with content and Section2 for h2 and so on. In this example, you should create a prop named something like level that takes a number of the level of the heading.

Input Components

These components take in input. When there is a complex type of input and/or repeated classnames/styling and/or complex data manipulation of raw input, you should create a seperate component to keep the main component more focused.

Rerendering Isolation

When you have a component that contains some state that is specific to an inner component or tag, that state will cause the entire larger component to rerender just for one inner element. This can cause performance issues. For example, if you have a modal that rerenders the entire page just to display or no longer show the modal, that is a problem. In these cases, it's best to seperate your the inner element or component into a seperate component and take the problematic state with it.