In programming, it's important to structure files or folders because it makes it easier for anyone with access to find project files. Concerning React's folder structures, there are many ways to organize a React project, and it can be quite confusing for developers to know which method to choose. Though React is a powerful tool, if it is not properly utilized, it can lead to problems when structuring programs, which is why this article presents the option of having better imports. Vanessa, a Developer at Fetchly Labs, explained how having better imports is one of the best ways to improve productivity, avoid errors, and simplify refactoring. With visual examples, this article explains the following: What files would look like with wrong imports, How to add export files, How to name an exports folder, Setting up the exports and the pros and cons associated with the process, Foolproofing imports, Setting up absolute imports, and Defining different absolute paths for different folders as well as the pros and cons. Finally, Vanessa suggested the best files to use in projects alongside clean code to boost productivity and prevent bugs when writing or re-writing code.
In programming, file or folder structuring is important because it makes it easier for anyone with access to a project to navigate through project files. However, when it comes to React's folder structures, the broad options for applications can be confusing as developers may find it hard to choose the best method for organizing a React project.
For a better understanding of React’s folder structures, kindly read the previous article on the topic,
“React: what's the best folder/file structure for your next project?” React in itself is quite powerful, but if it is not properly used, it can lead to a lot of headaches when structuring folders. Thankfully, one of the things that can easily help with productivity, avoiding errors, and making refactoring effortless is having better imports.
What Files Would Look Like with Improper Imports
When organizing a React project by file type, it’s possible to end up with the following situation on any project’s screen files:
Technically speaking, there is nothing wrong with it. However, the files can end up looking cluttered with many lines to cover up the needed imports. Also, as the project grows, it’s completely normal to feel the need to add more headings. Since there may be a lot of components in the content folder, having a folder for headings sounds logical.
Manually importing every single component and adding some of them into a new folder would require changing all imports on every single screen that utilizes them.
While if there is an index file containing all exports for a user's components, it would only be necessary to change that single file in order to affect the whole project. So, instead of having the imports as mentioned earlier, something like this would be seen:
Adding the Exports File
In the event that a project has the following folder structure: It would be best to simply add an index.js file in the root components folder. It is also worth mentioning that this does not apply to components only.
For example, someone can have an export folder for assets such as images, fonts, and icons. If there is a folder that contains their assets and within the folder, there is another folder for their icons, that is where the index of the icon would be.
Naming an Exports Folder
When naming an exports folder, It’s worth mentioning that a file with a different name can be added, but it wouldn’t be as optimized. If a path to a folder is set up without specifying any files, React will look for an index. Therefore, it would be best to always name your exports index.js for better optimization.
Setting up the Exports
After the file has been acquired, the next step would be to start adding the components that need to be exported. Keep in mind that there is no need to import the files in order to be able to export them. Importing to export is mere repetition and should be avoided. Codes should remain
DRY!
Pros and Cons
Pros: Having an export file makes the code look less cluttered, and it is also easier to rearrange files and folders with no hassle whatsoever.
Cons: If a project has several components already, adding an export file will require a lot of manual exporting.
Foolproofing Imports
Any team trying to divide screen files into folders because it makes more sense can use this approach if they don't have an index file with all imports. However, if they’ve already done so, they simply need to change the path of the component import by a single line. Sounds good, right? But there's a way to make it even better.
To completely foolproof our imports, we can also add absolute imports. This means that instead of having to “go back” to the /src, with `../../..` for instance, and from there to the desired folder, we would have an absolute pathing, such as `src/folder`, no matter how nested the file is.
Setting up Absolute Imports
This feature was implemented in
create-react-app v3, and also works for Typescript projects. To add it to a JS-based React project, the first step is to add a `jsconfig.json` file in the project’s root. But when working with Typescript, it’s best to add the code to the`tsconfig.json`, adding a “baseUrl” inside the “compilerOptions”, as well as including the “src”:
Taking it to the next level
To take a step further and define different absolute paths for different folders, we can simply what's needed for the “compilerOptions”:
Pros and Cons
Pros: It’s the same as having an export file!
Cons: It will require some configuration in order to make it work.
So what should I use in my project at the end of the day?
Ideally, it is always advisable to use both an index export file and absolute imports in projects. Simple and clean code can boost productivity and also prevent unexpected bugs when writing (or re-writing) code. As always, there are benefits and drawbacks when applying it to existing projects, but sometimes losing a few hours setting them up can save a developer day of debugging.
*This is not the official Fetchly opinion but the opinion of the writer who is employed by Fetchly*