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.
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.
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.
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.
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.
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
h1 followed with content and
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.
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.
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.