I bet, for many developers or for me at least, there’s often a dilemma in the initial phase of a development project.\nThat is …
\n_ How to set up the folder structure and file naming conventions, a.k.a the project structure? _
\nProject structure plays a critical role in the long-term productivity, maintainability and architectural excellency of any development project.\nHaving laid it out myself as well as worked on someone else’s setup, I learned it the hard way.
\nAs ReactJS is my primary FE library of choice, this article will depict a sample ReactJS project and its structure.
\nPrecaution: Nothing here is written in rocks, the methodology I am describing here is just one of many approaches 😏
One of the questions I often face is regarding to how structure files and folders. In this post, I am starting off with a minimum structure, the one created with create-react-app.\nThe create-react-app generates a basic project for us, containing in its root, the files: .gitignore, package.json, README.md, yarn.lock
It also generates the folders: public and src. The last one is where we keep our source code.
I tried the separation between Containers and Presentation Components in the project’s root folder. I mean, inside src, I had a folder named components and another folder named containers:
However, this kind of approach introduced some issues like:
\nYou don’t have clear rules about what is a Container and what is a Presentational Component. The difference between each other can be subjective and when you are in a team, it will be hard to have all the developers agreeing and judging equally this matter.\n
Even when you decide a component fits in one of the specific types, it’s easy to get it changed along the project lifetime, and forcing you to move it from components to containers folder and vice-versa.
\nComponents should have declarative and unique names in the application, to avoid confusion about the responsibility of each one. However, the above approach opens a breach to having two components with the same name, one being a container and other being a presentational.
\nYou have to constantly navigate between containers and components folders, even when working in a single feature. Because it’s common that a single feature has components of the two types.
\nFor those reasons, I realized that when organizing folders and files, it’s irrelevant to split the components by the concept of presentational vs container.
\nInside the components folder, I would group the files by module/feature.
For example, for a CRUD of user, the structure would be as the following:
\nThe test files stay with the file that is being tested. In the above case, the test for Form.jsx would stay in its same folder and would be named as Form.spec.jsx
Beyond separating the components by modules, I’d also include a UI folder inside src/components, to keep all the generic components in it.\nUI components are components generic enough not to belong to a module and likely to be reused. I could go with Common instead of UI, but the name UI represents the difference well with logic.\nExamples of these components are: Buttons, Inputs, Checkboxes, Selects, Modals, Data display elements, etc…
The name we give to the components, should be clear and unique in the application, in order to make them easier to find and to avoid possible confusions.\nA component’s name is very handy when we need to debug using tools as React Dev Tools, and when run time errors happen in the application. The error always come with the component name where it happened.\nBasically, a component that is located at: components/User/List.jsx would be named as UserList.\nWhen the file is inside a folder with same name, we don’t need to repeat the name. That said, components/User/Form/Form.jsx, would be named as UserForm and not as UserFormForm.
I use sublime or VSCode as the IDE for the web development, and they support the fuzzy search.\nTherefore, file name not being identical to the component name doesn’t pose any difficulty in search.\n
Screens, as the name already suggests, would be the screens that we have in the application.\nFor users scope, we would have a screen for the user list, a screen for creating a user and a screen for editing a user.\nA screen is where I use components to compose a page. Most of the time, the screen would’t contain any logic and would be a functional component.
import React from 'react';\nimport UserForm from '../../components/User/Form/Form';\n\nconst ScreensUserForm = ({ match: { params } }) => (\n <div>\n <h1>\n {`${!params.id ? 'Create' : 'Update'}`} User\n </h1>\n <UserForm id={params.id} />\n </div>\n);\n\nexport default ScreensUserForm;And the folder structure and component naming within the screens folder should follow the same convention as the components folder, except that we conveniently add a prefix to descriminate the screen components, i.e. ScreensUserForm\nThe final structure of this example project would look like:
Note that Root.jsx is the component where routing is defined
Personally, I would put some non-component files in the relevantly named folders directly under src folder.\nFor example, utils for the helper functions, hooks for custom hooks, and services for API handlers.
This approach is definitely a work in progress as I’d constantly seek for a better alternative, be it an enhanced version of this one or a completely different one.\nThe foremost question is if I really need Screens folder, but it seems convenient at the moment.
To be continued …
","frontmatter":{"title":"Developer's Dilemma - Folder Structure and Component Naming","description":"I bet, for many developers or for me at least, there’s","date":"2020-05-14T00:00:00.000Z","slug":"/blog/folder-structure-n-component-naming","tags":["Blogging","Tech"]}}},"pageContext":{}}, "staticQueryHashes": ["2009693873","2077189868","3303540520","3505212370","3825832676"]}