Β
- NodeJS 16
- NPM
Β
Install all the dependencies.
Β
Build the app using the env file for the environment. eg: npm run build:local
.
Available environments: 'local', 'dev', 'staging'.
Use npm run build
only for prod.
Β
Start the app using the env file for the environment. eg: npm run start:dev
.
Available environments: 'local', 'dev', 'staging'.
Use npm run start
only for prod.
Β
Will run the tests
On every commit
the linting process will be executed.
On every push
tests will be executed.
Β
- ViteJS
- ReactJS
- Typescript
- react-error-boundary
- Tailwind CSS v3.
Could be styled-components, emotions, etc
Could be any of the following:
- Ant Design.
- Material UI.
- Bulma.
- Date-fns
- Jest + React Testing Library (plus some plugins).
- React Query
- Axios
- Husky & Lint staged
- Runs prettier and eslint on @pre-commit & jest/tests on @pre-push
- React Router 6.
- ESlint & Prettier Configured
- Lints
- airbnb
- react
- react hooks
- typescript
- jsx-a11y
- jest
- testing library
- vscode settings & extension recommendations
.editorconfig
file
Β
- ES7 React/Redux
- ESLint
- Prettier
- EditorConfig for VS Code
- DotENV
- Tailwind CSS IntelliSense
Β
- Auto Close Tag
- Auto Rename Tag
- Auto import - ES6
- Path Intellisense
- TODO Highlight
Folder structure is based on productivity and some best practices (NextJS, public recommendations, etc):
src
βββ App.css * Main styles to load or overwrite for any UI components library .
βββ App.tsx * Main app component.
βββ index.css * Main app styles and import tailwind base styles.
βββ main.tsx * Entry point of the application (any initial configuration or plugins).
βββ assets * Assets that are imported into your components(images, custom svg, etc).
β βββ ...
βββ components * Components of the projects that are not the main views.
β βββ ui * Generic and reusable across the whole app. Presentational components eg. Buttons, Inputs, Checkboxes.
β βββ layout * Unique and one time use components that will help with app structure (guards, navigation, etc).
β βββ shared * Reusable components across different domains or features.
β βββ <domain component> * Belong to a specific domain. Reusable in different Pages.
β βββ ...
βββ plugins * Init and config plugins(axios, react-query, react-feature-flags, etc).
β βββ ...
βββ services * All the common services. e.g. Api, hubs, store (redux/context API/ Mobx), etc.
β βββ api * Abstractions for making API requests
β β βββ base * Abstract classes for all the API's.
β β βββ authentication.ts * Authentication API for login, reset password, etc.
β β βββ ...
β βββ context * All the Contexts use din the app for Auth, alerts, etc
β βββ ...
βββ theme * Global/Common styles configuration (variables, main theme, mixins, etc) on Sass/Less.
βββ test * Utilities, mocks and config files for tests.
βββ hooks * Custom hooks to isolate reusable logic.
βββ models * Constructors that will mold incoming and outgoing server data into repeatable and scalable objects.
βββ constants * Anything referenced globally and no Dynamic information.
βββ utils * Functions and utilities (for env variables, for tests, for regex value testing, filters, etc.)
βββ routes * All the possible routes/navigation of the app.
βββ pages * Presentational components that represents pages/views.
β βββ private * Private views (authenticated user)
β β βββ ...
β βββ public * Public views (guest user)
β β βββ ...
β βββ ... * Shared views
βββ .vscode * VS Code workspace settings to work with ESLint rules and formatting
(you can also lint or fix on save π).
Some important root/config files
.
βββ src
β βββ jest.setup.ts * Jest extra configuration.
βββ .editorconfig * Coding styles (also by programming language).
βββ .env * Environment variables (env.production, env.dev, env.development, env.staging, etc).
βββ .eslintrc.json * ESLint configuration and rules.
βββ .prettierrc * Formatting Prettier options.
βββ tsconfig.js * Typescript configuration.
βββ postcss.config.js * POST CSS configuration.
βββ tailwind.config.js * Tailwind CSS configuration.
βββ vite.config.ts * ViteJS configuration.
βββ jest.config.js * Jest configuration for tests.
Here are a few important conventions:
Since JSX is not standard JS it should go into it's own extension ie. .ts
for TypeScript, .jsx
for JSX.
Now days, most of the IDE's support both extensions for ReactJs, so more important reason today is that helps to indicate what it is: a component or plain js?.
-
Component names should always be multi-word, except for root
App
components. UseUserCard
orProfileCard
instead ofCard
for example. Each component should be in its own file.Gives more meaning and context of what the component does.
-
Components files should be always PascalCase/kebab-case except for HOC's. Use
UserCard.jsx
oruser-card.jsx
.PascalCase works best with autocompletion in code editors, as itβs consistent with how we reference components in JS(X) and templates, wherever possible. However, mixed case filenames can sometimes create issues on case-insensitive file systems, which is why kebab-case is also perfectly acceptable.
-
Components are named accordingly to it's relative path to components or src. Given that, a component located at
src/components/User/List.jsx
would be named asUserList
. A component located atsrc/screens/User/List
would be named asScreensUserList
. -
Components that are in a folder with same name, donβt repeat the name in the component. Considering that, a component located at
src/components/User/List/List.jsx
would be named asUserList
and NOT asUserListList
.The name we give to the components, should be clear and unique in the application, in order to make them being easier to find and to avoid possible confusions. Easy search inside the project.
-
Components that are only used once per page should begin with the prefix βTheβ, to denote that there can be only one. For example for a navbar or a footer you should use
TheNavbar.jsx
orTheFooter.jsx
.This does not mean the component is only used in a single page, but it will only be used once per page. These components never accept any props, since they are specific to your app, not their context within your app. If you find the need to add props, itβs a good indication that this is actually a reusable component that is only used once per page for now.
-
High Order Components (HOC) file and folder name in lowerCamelCase and use the prefix
with
.Generic convention
-
Always use full name instead of abbreviation in the name of your components. For example donβt use
UDSettings
, use insteadUserDashboardSettings
.Keep things clear
-
Each page is a react class component having some state. A page component uses other components to assemble the page like lego blocks.
Single entry point by feature or page. Keep the pages in a separated folder in the root of src, because they will be grouped accordingly to the route definition and not by modules.
-
Keep components shallow. If a components has a lot of nested markup then the chances of reusing it decreases. Instead we should take advantage of composition. It saves us from prop drilling or having to reach out to context api.
Reusable and Readable code. Passing down props to multiple child components is what they call a code smell.
-
Presentational components are those who donβt have internal state. Their role is to show certain pieces of UI or Layout. They are provided data via props or context api or state management.
-
Container components are those which deals with business logic. They usually have some state and only render presentational components based on the logic.
This way Presentational and Container components complete the puzzle together. By dividing the responsibilities, code becomes easier to maintain and debug.
- Use a central export file (Barrel export ->
index.ts
) in the components directory. With this file we can just import all of our components into it and export them. This will allow us to import components into any file from the same place. - Group components by
module/feature
insidecomponents folder
. - Keep generic components by context inside
src/components/ui
orsrc/components/layout
. - Keep pages simple, with minimum structure and code.
- Group pages accordingly to route definition. For a route
/user/list
we would have a page located at/src/pages/User/List.jsx
.