React Component Library
In any React project, you’re often tasked with creating components that can be reused all over the project multiple times. Once you’ve created this component you might create index files for each of them so they are easily exported, imported, and used. A couple of things you have to keep in mind when you are creating a custom component library is
Folder Structure
With the freedom and ease of use that a React project can provide, there are countless ways you can create and publish components in React, however, without some sort of guidelines, stuff can get messy.
-- Type
Similar stuff lives together. Components should live in a components folder and the styles in a styles folder. However, this still depends on how you choose to organize your different files.
As the number of components increases, it becomes more difficult to work and find individual components.
Issues also may arise when you can’t find a dependent file of a component in the same place. Components might have their own stories, styles, and tests placed away in different folders. This might make it harder to track if something is missing or not.
Another issue is when you realize you have a component logic that only relates to a single component. It might be an overkill to have a folder dedicated to that single logic, however after it is created, other developers might find it useful when building upon other components. However, the creation and placement in the first place are not obvious.
Moving or editing individual components is another tedious task you will encounter when you organize your components by type by type. You will have to go through all the folders and find a component’s dependencies. Refactoring is not impossible however it is more error-prone.
-- Locality
Locality can be best described by encapsulation. A component and all its necessary dependencies live close to each other. A component and its styles, utils, and tests are placed in a folder with the same name as the component itself. Necessary files also have the component name, their type, and extension in their names.
Locality organization is more flexible and better suited for projects with numerous components. When we want to modify a component and then its corresponding dependencies, we would only need to look at a single place.
A new component is also easy to add, it only requires creating a folder with the component name, and then adding the supporting files in the same folder. In case the component is required to scale, all its new complexities can live in the same place with its hierarchy.
Locality allows for more flexibility since the growth of a component will follow a consistent structure in its domain of existence. If only one component requires a utils file, you can add it to just that component without having to add it for every other component that may not need them.
Moving components is also much easier since the dependencies of the component are all contained in the same place. Relative imports within that same folder help in persisting the stability of the code.
Avoiding index.js
An index.js is unnecessary in both aforementioned approaches because it adds another layer of indirection. A similar name for different components is confusing and hence should be avoided.
Having the component name, along with a prefix that explains the intent of the file makes the components and their dependencies more searchable and modifiable.
Mixing it Up
In case you find it difficult for finding the right approach, you can use both. A custom approach can help when you want to keep your logic and components separate.
Adopted: https://blog.sethcorker.com/how-to-organise-react-components/
#LearningFullTime #React #Practice
In any React project, you’re often tasked with creating components that can be reused all over the project multiple times. Once you’ve created this component you might create index files for each of them so they are easily exported, imported, and used. A couple of things you have to keep in mind when you are creating a custom component library is
Folder Structure
With the freedom and ease of use that a React project can provide, there are countless ways you can create and publish components in React, however, without some sort of guidelines, stuff can get messy.
-- Type
Similar stuff lives together. Components should live in a components folder and the styles in a styles folder. However, this still depends on how you choose to organize your different files.
As the number of components increases, it becomes more difficult to work and find individual components.
Issues also may arise when you can’t find a dependent file of a component in the same place. Components might have their own stories, styles, and tests placed away in different folders. This might make it harder to track if something is missing or not.
Another issue is when you realize you have a component logic that only relates to a single component. It might be an overkill to have a folder dedicated to that single logic, however after it is created, other developers might find it useful when building upon other components. However, the creation and placement in the first place are not obvious.
Moving or editing individual components is another tedious task you will encounter when you organize your components by type by type. You will have to go through all the folders and find a component’s dependencies. Refactoring is not impossible however it is more error-prone.
-- Locality
Locality can be best described by encapsulation. A component and all its necessary dependencies live close to each other. A component and its styles, utils, and tests are placed in a folder with the same name as the component itself. Necessary files also have the component name, their type, and extension in their names.
Locality organization is more flexible and better suited for projects with numerous components. When we want to modify a component and then its corresponding dependencies, we would only need to look at a single place.
A new component is also easy to add, it only requires creating a folder with the component name, and then adding the supporting files in the same folder. In case the component is required to scale, all its new complexities can live in the same place with its hierarchy.
Locality allows for more flexibility since the growth of a component will follow a consistent structure in its domain of existence. If only one component requires a utils file, you can add it to just that component without having to add it for every other component that may not need them.
Moving components is also much easier since the dependencies of the component are all contained in the same place. Relative imports within that same folder help in persisting the stability of the code.
Avoiding index.js
An index.js is unnecessary in both aforementioned approaches because it adds another layer of indirection. A similar name for different components is confusing and hence should be avoided.
Having the component name, along with a prefix that explains the intent of the file makes the components and their dependencies more searchable and modifiable.
Mixing it Up
In case you find it difficult for finding the right approach, you can use both. A custom approach can help when you want to keep your logic and components separate.
Adopted: https://blog.sethcorker.com/how-to-organise-react-components/
#LearningFullTime #React #Practice