@pplancq/react-template 1.7.0 → 1.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.lintstagedrc.js +1 -0
- package/CHANGELOG.md +7 -0
- package/_README.md +10 -2
- package/package.json +19 -17
- package/public/index.html +2 -5
- package/scripts/lint.js +12 -0
- package/src/api/README.md +10 -9
- package/src/assets/README.md +12 -9
- package/src/components/README.md +3 -4
- package/src/config/README.md +12 -10
- package/src/forms/README.md +21 -10
- package/src/hooks/README.md +11 -15
- package/src/pages/README.md +12 -9
- package/src/providers/README.md +17 -20
- package/src/routing/README.md +18 -22
- package/src/types/README.md +5 -4
- package/src/ui/README.md +26 -23
- package/src/utils/README.md +15 -13
package/.lintstagedrc.js
CHANGED
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
## @pplancq/react-template [1.8.0](https://github.com/pplancq/dev-tools/compare/@pplancq/react-template@1.7.0...@pplancq/react-template@1.8.0) (2024-08-27)
|
|
2
|
+
|
|
3
|
+
### Features
|
|
4
|
+
|
|
5
|
+
* **react-template:** bump jsdom 24.1.1 to 25.0.0 ([c3c8993](https://github.com/pplancq/dev-tools/commit/c3c8993e852a01ba0366d78e6597fc01b00aa7f9))
|
|
6
|
+
* **react-template:** update scripts command for lint code ([50b50f8](https://github.com/pplancq/dev-tools/commit/50b50f88b427c4eef11b81142aad8fb09a908ce3))
|
|
7
|
+
|
|
1
8
|
## @pplancq/react-template [1.7.0](https://github.com/pplancq/dev-tools/compare/@pplancq/react-template@1.6.0...@pplancq/react-template@1.7.0) (2024-08-16)
|
|
2
9
|
|
|
3
10
|
### Features
|
package/_README.md
CHANGED
|
@@ -36,6 +36,10 @@ You will also see lint errors in the console.
|
|
|
36
36
|
|
|
37
37
|
### `npm test`
|
|
38
38
|
|
|
39
|
+
Launches the test runner.
|
|
40
|
+
|
|
41
|
+
### `npm run test:watch`
|
|
42
|
+
|
|
39
43
|
Launches the test runner in interactive mode.
|
|
40
44
|
|
|
41
45
|
### `npm run build`
|
|
@@ -51,14 +55,18 @@ Your application is ready to be deployed!
|
|
|
51
55
|
|
|
52
56
|
Allows you to see lint errors without fixing them. This command initiates the linting process with three linters: **eslint**, **stylelint**, and **tsc** (TypeScript Compiler).
|
|
53
57
|
|
|
54
|
-
### `npm run eslint:fix`
|
|
58
|
+
### `npm run lint:eslint:fix`
|
|
55
59
|
|
|
56
60
|
Allows you to fix eslint errors.
|
|
57
61
|
|
|
58
|
-
### `npm run stylelint:fix`
|
|
62
|
+
### `npm run lint:stylelint:fix`
|
|
59
63
|
|
|
60
64
|
Allows you to fix style lint errors.
|
|
61
65
|
|
|
66
|
+
### `npm run lint:prettier:fix`
|
|
67
|
+
|
|
68
|
+
Allows you to fix prettier lint errors.
|
|
69
|
+
|
|
62
70
|
### `npm run remove:demo`
|
|
63
71
|
|
|
64
72
|
To remove the demo application.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@pplancq/react-template",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.8.0",
|
|
4
4
|
"license": "MIT",
|
|
5
5
|
"description": "react template",
|
|
6
6
|
"author": "pplancq <paul.plancq@outlook.fr>",
|
|
@@ -15,12 +15,14 @@
|
|
|
15
15
|
"build": "webpack --mode production",
|
|
16
16
|
"test": "vitest run",
|
|
17
17
|
"test:watch": "vitest",
|
|
18
|
-
"lint": "
|
|
19
|
-
"eslint": "eslint src
|
|
20
|
-
"eslint:fix": "eslint src
|
|
21
|
-
"stylelint": "stylelint \"src/**/*.{scss,css}\"",
|
|
22
|
-
"stylelint:fix": "stylelint \"src
|
|
23
|
-
"
|
|
18
|
+
"lint": "node scripts/lint.js",
|
|
19
|
+
"lint:eslint": "eslint \"{mocks,public,src}/**/*.{js,jsx,ts,tsx}\"",
|
|
20
|
+
"lint:eslint:fix": "eslint \"{mocks,public,src}/**/*.{js,jsx,ts,tsx}\" --fix",
|
|
21
|
+
"lint:stylelint": "stylelint \"src/**/*.{scss,css}\"",
|
|
22
|
+
"lint:stylelint:fix": "stylelint \"src/**/*.{scss,css}\" --fix",
|
|
23
|
+
"lint:prettier": "prettier \"{mocks,public,src}/**/*.!(js|jsx|ts|tsx|scss|css)\" --check --ignore-unknown",
|
|
24
|
+
"lint:prettier:fix": "prettier \"{mocks,public,src}/**/*.!(js|jsx|ts|tsx|scss|css)\" --write --ignore-unknown",
|
|
25
|
+
"lint:tsc": "tsc --noEmit",
|
|
24
26
|
"package:check": "npm exec --yes package-lock-utd@1.1.3",
|
|
25
27
|
"remove:demo": "node ./scripts/removeDemo.js",
|
|
26
28
|
"migrate:vite": "node ./scripts/migrateToVite.js",
|
|
@@ -36,11 +38,11 @@
|
|
|
36
38
|
"dependencies": {
|
|
37
39
|
"@hookform/resolvers": "^3.9.0",
|
|
38
40
|
"@tanstack/react-query": "^5.51.23",
|
|
39
|
-
"@tanstack/react-query-devtools": "^5.
|
|
41
|
+
"@tanstack/react-query-devtools": "^5.52.1",
|
|
40
42
|
"react": "^18.2.0",
|
|
41
43
|
"react-dom": "^18.3.1",
|
|
42
|
-
"react-hook-form": "^7.
|
|
43
|
-
"react-router-dom": "^6.26.
|
|
44
|
+
"react-hook-form": "^7.53.0",
|
|
45
|
+
"react-router-dom": "^6.26.1",
|
|
44
46
|
"yup": "^1.4.0"
|
|
45
47
|
},
|
|
46
48
|
"devDependencies": {
|
|
@@ -52,22 +54,22 @@
|
|
|
52
54
|
"@pplancq/prettier-config": "*",
|
|
53
55
|
"@pplancq/stylelint-config": "*",
|
|
54
56
|
"@pplancq/webpack-config": "*",
|
|
55
|
-
"@testing-library/jest-dom": "^6.
|
|
57
|
+
"@testing-library/jest-dom": "^6.5.0",
|
|
56
58
|
"@testing-library/react": "^16.0.0",
|
|
57
59
|
"@testing-library/user-event": "^14.5.1",
|
|
58
|
-
"@types/react": "^18.3.
|
|
60
|
+
"@types/react": "^18.3.4",
|
|
59
61
|
"@types/react-dom": "^18.3.0",
|
|
60
62
|
"@vitejs/plugin-react": "^4.3.1",
|
|
61
63
|
"@vitest/coverage-v8": "^2.0.5",
|
|
62
64
|
"concurrently": "^8.2.2",
|
|
63
65
|
"eslint": "^8.57.0",
|
|
64
66
|
"eslint-plugin-prettier": "^5.2.1",
|
|
65
|
-
"husky": "^9.1.
|
|
66
|
-
"jsdom": "^
|
|
67
|
-
"lint-staged": "^15.2.
|
|
67
|
+
"husky": "^9.1.5",
|
|
68
|
+
"jsdom": "^25.0.0",
|
|
69
|
+
"lint-staged": "^15.2.9",
|
|
68
70
|
"msw": "^2.3.5",
|
|
69
71
|
"prettier": "^3.3.3",
|
|
70
|
-
"stylelint": "^16.8.
|
|
72
|
+
"stylelint": "^16.8.2",
|
|
71
73
|
"stylelint-prettier": "^5.0.2",
|
|
72
74
|
"tsc-files": "^1.1.4",
|
|
73
75
|
"typescript": "^5.5.4",
|
|
@@ -76,7 +78,7 @@
|
|
|
76
78
|
"vitest": "^2.0.5",
|
|
77
79
|
"vitest-axe": "^1.0.0-pre.3",
|
|
78
80
|
"vitest-sonar-reporter": "^2.0.0",
|
|
79
|
-
"webpack": "^5.
|
|
81
|
+
"webpack": "^5.94.0",
|
|
80
82
|
"webpack-cli": "^5.1.4",
|
|
81
83
|
"webpack-dev-server": "^5.0.4"
|
|
82
84
|
},
|
package/public/index.html
CHANGED
|
@@ -1,13 +1,10 @@
|
|
|
1
|
-
<!
|
|
1
|
+
<!doctype html>
|
|
2
2
|
<html lang="fr">
|
|
3
3
|
<head>
|
|
4
4
|
<meta charset="utf-8" />
|
|
5
5
|
<link rel="icon" href="/favicon.ico" />
|
|
6
6
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
7
|
-
<meta
|
|
8
|
-
name="description"
|
|
9
|
-
content="Web site created using react-template"
|
|
10
|
-
/>
|
|
7
|
+
<meta name="description" content="Web site created using react-template" />
|
|
11
8
|
<title>React App</title>
|
|
12
9
|
</head>
|
|
13
10
|
<body>
|
package/scripts/lint.js
ADDED
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
// eslint-disable-next-line import/no-extraneous-dependencies
|
|
2
|
+
const concurrently = require('concurrently');
|
|
3
|
+
|
|
4
|
+
const { result } = concurrently(['npm:lint:eslint', 'npm:lint:tsc', 'npm:lint:stylelint', 'npm:lint:prettier'], {
|
|
5
|
+
prefixColors: 'auto',
|
|
6
|
+
maxProcesses: process.env.CI ? 1 : undefined,
|
|
7
|
+
});
|
|
8
|
+
|
|
9
|
+
result.then(
|
|
10
|
+
() => process.exit(0),
|
|
11
|
+
() => process.exit(1),
|
|
12
|
+
);
|
package/src/api/README.md
CHANGED
|
@@ -1,21 +1,22 @@
|
|
|
1
1
|
# 📁 api
|
|
2
2
|
|
|
3
3
|
The "api" folder is designed to handle calls to native APIs using the fetch function. These calls are essential for retrieving real-time data from external sources, such as remote servers or web services.
|
|
4
|
+
|
|
4
5
|
## 📑 Table of Contents
|
|
5
|
-
- [Folder Organization](#folder-organization)
|
|
6
|
-
- [Usage](#usage)
|
|
7
|
-
- [Error Handling](#error-handling)
|
|
8
|
-
- [Security](#security)
|
|
9
|
-
- [Documentation](#documentation)
|
|
10
|
-
- [Testing](#testing)
|
|
11
|
-
- [Best Practice](#best-practice)
|
|
12
6
|
|
|
7
|
+
- [Folder Organization](#folder-organization)
|
|
8
|
+
- [Usage](#usage)
|
|
9
|
+
- [Error Handling](#error-handling)
|
|
10
|
+
- [Security](#security)
|
|
11
|
+
- [Documentation](#documentation)
|
|
12
|
+
- [Testing](#testing)
|
|
13
|
+
- [Best Practice](#best-practice)
|
|
13
14
|
|
|
14
15
|
## <span id="folder-organization">Folder Organization</span>
|
|
15
16
|
|
|
16
17
|
The "api" folder can be organized as follows :
|
|
17
18
|
|
|
18
|
-
1. **API Endpoints** : Create a separate file for each API you are calling. For example, if you have a user management API and a data retrieval API, you can have the files `users.ts`
|
|
19
|
+
1. **API Endpoints** : Create a separate file for each API you are calling. For example, if you have a user management API and a data retrieval API, you can have the files `users.ts` and `data.ts` to handle these respective calls.
|
|
19
20
|
|
|
20
21
|
2. **Call Functions** : Inside each API file, define dedicated functions to make `fetch` requests to the corresponding endpoints. These functions can also include handling responses and errors.
|
|
21
22
|
|
|
@@ -61,4 +62,4 @@ export const fetchApi = (uri, options) => {
|
|
|
61
62
|
};
|
|
62
63
|
```
|
|
63
64
|
|
|
64
|
-
In this example, the fetchApi function extends the default fetch function by automatically including an API token in the request header. This practice helps centralize common configurations and promotes consistency across your application.
|
|
65
|
+
In this example, the fetchApi function extends the default fetch function by automatically including an API token in the request header. This practice helps centralize common configurations and promotes consistency across your application.
|
package/src/assets/README.md
CHANGED
|
@@ -3,9 +3,10 @@
|
|
|
3
3
|
The "assets" folder is a commonly used directory in a React application to store static resources such as images, CSS files, fonts, JSON data files, icons, and other non-JavaScript files used in your application. These resources are typically needed to style and customize the user interface of your application.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
6
|
+
|
|
7
|
+
- [Why Use an "assets" Folder](#folder-organization)
|
|
8
|
+
- [Usage Example](#usage)
|
|
9
|
+
- [Best Practice](#best-practice)
|
|
9
10
|
|
|
10
11
|
## <span id="folder-organization">Why Use an "assets" Folder?</span>
|
|
11
12
|
|
|
@@ -20,7 +21,7 @@ The "assets" folder is a commonly used directory in a React application to store
|
|
|
20
21
|
To use an image stored in the "assets" folder, you can reference its relative path in your JavaScript or JSX code like this:
|
|
21
22
|
|
|
22
23
|
```javascript
|
|
23
|
-
import logo from '@Front/assets/images/logo.png'
|
|
24
|
+
import logo from '@Front/assets/images/logo.png';
|
|
24
25
|
|
|
25
26
|
export const App = () => {
|
|
26
27
|
return (
|
|
@@ -29,7 +30,7 @@ export const App = () => {
|
|
|
29
30
|
{/* ... other elements of the application */}
|
|
30
31
|
</div>
|
|
31
32
|
);
|
|
32
|
-
}
|
|
33
|
+
};
|
|
33
34
|
```
|
|
34
35
|
|
|
35
36
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
@@ -37,15 +38,17 @@ export const App = () => {
|
|
|
37
38
|
When it comes to styling and managing assets, adopting the following practices can enhance maintainability and structure in your project:
|
|
38
39
|
|
|
39
40
|
### - Global CSS Rules
|
|
40
|
-
|
|
41
|
+
|
|
42
|
+
Define all global CSS rules, such as resets, fonts, and general styling, in a centralized stylesheet (in the css folder under the assets ).
|
|
41
43
|
|
|
42
44
|
This ensures consistency across your entire application.
|
|
43
45
|
|
|
44
46
|
### - CSS Modules
|
|
47
|
+
|
|
45
48
|
For component-specific styles, leverage CSS Modules to encapsulate styles within the component scope.
|
|
46
49
|
|
|
47
|
-
|
|
50
|
+
This helps prevent unintentional styling conflicts and promotes a modular approach to styling.
|
|
48
51
|
|
|
49
|
-
|
|
50
|
-
***By adhering to these practices, you create a clear separation between global styles and component-specific styles, making your codebase more maintainable and scalable.***
|
|
52
|
+
---
|
|
51
53
|
|
|
54
|
+
**_By adhering to these practices, you create a clear separation between global styles and component-specific styles, making your codebase more maintainable and scalable._**
|
package/src/components/README.md
CHANGED
|
@@ -3,9 +3,9 @@
|
|
|
3
3
|
The "components" folder is a crucial element of any React application. It is used to organize and store reusable components that make up the user interface of your application. React components are self-contained pieces of the user interface, each having its own logic and rendering.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
- [Why Use a "components" Folder](#folder-organization)
|
|
7
|
-
- [Usage](#usage)
|
|
8
6
|
|
|
7
|
+
- [Why Use a "components" Folder](#folder-organization)
|
|
8
|
+
- [Usage](#usage)
|
|
9
9
|
|
|
10
10
|
## <span id="folder-organization">Why Use a "components" Folder?</span>
|
|
11
11
|
|
|
@@ -15,7 +15,6 @@ The "components" folder is a crucial element of any React application. It is use
|
|
|
15
15
|
|
|
16
16
|
3. **Better Organization** : Organizing components in a dedicated folder helps clearly distinguish components from other elements of the application, such as styles, images, or configuration files.
|
|
17
17
|
|
|
18
|
-
|
|
19
18
|
## <span id="usage">🧑🏻💻 Usage Example </span>
|
|
20
19
|
|
|
21
20
|
Suppose you have a "Header.js" component in the "components" folder. You can import and use it in other parts of your application like this:
|
|
@@ -30,5 +29,5 @@ export const App = () => {
|
|
|
30
29
|
{/* ... other elements of the application */}
|
|
31
30
|
</div>
|
|
32
31
|
);
|
|
33
|
-
}
|
|
32
|
+
};
|
|
34
33
|
```
|
package/src/config/README.md
CHANGED
|
@@ -3,16 +3,17 @@
|
|
|
3
3
|
The "config" folder is intended to store all important configurations and utilities needed for our React project. Bringing together this information in one place makes managing configuration settings easier and ensures better code organization.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
6
|
+
|
|
7
|
+
- [Folder Organization](#folder-organization)
|
|
8
|
+
- [Content Example](#content-example)
|
|
9
|
+
- [Usage](#usage)
|
|
10
|
+
- [Best Practice](#best-practice)
|
|
10
11
|
|
|
11
12
|
## <span id="folder-organization">Folder Organization</span>
|
|
12
13
|
|
|
13
14
|
Within the "config" folder, you can find the following elements:
|
|
14
15
|
|
|
15
|
-
1. **Configuration Files** : Files containing variables and configuration parameters, such as `apiConfig.ts`
|
|
16
|
+
1. **Configuration Files** : Files containing variables and configuration parameters, such as `apiConfig.ts` for configurations related to API calls, `appConfig.ts` for general application settings, `queryClientConfig.ts` for react-query-related configuration, etc.
|
|
16
17
|
|
|
17
18
|
2. **Configuration Scripts** : Scripts or utilities that facilitate dynamic configuration of the application, such as theme configuration, language management, etc.
|
|
18
19
|
|
|
@@ -28,12 +29,10 @@ Here is an example folder structure for "config":
|
|
|
28
29
|
├── 📄 translationConfig.ts
|
|
29
30
|
```
|
|
30
31
|
|
|
31
|
-
|
|
32
32
|
## <span id="usage">🧑🏻💻Usage in the Project</span>
|
|
33
33
|
|
|
34
34
|
When you need to access a specific configuration in your code, import the appropriate file from the "config" folder. For example:
|
|
35
35
|
|
|
36
|
-
|
|
37
36
|
```javascript
|
|
38
37
|
// Example of using an API configuration
|
|
39
38
|
import { apiEndpoint } from '@Front/config/apiConfig';
|
|
@@ -46,16 +45,19 @@ import { appName } from '@Front/config/appConfig';
|
|
|
46
45
|
```
|
|
47
46
|
|
|
48
47
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
48
|
+
|
|
49
49
|
Efficient configuration management is crucial for maintaining a clear and organized codebase. Follow these best practices for managing configuration files:
|
|
50
50
|
|
|
51
51
|
#### - Context-Specific Configuration
|
|
52
|
-
|
|
52
|
+
|
|
53
|
+
Separate configuration files based on different contexts, such as API configurations, QueryClient configurations, translations, etc.
|
|
53
54
|
|
|
54
55
|
This helps in better organization and ease of maintenance.
|
|
55
56
|
|
|
56
57
|
#### - File Naming Convention
|
|
57
|
-
Suffix configuration files with `Config` to enhance visibility and make it easier to identify configuration files at a glance.
|
|
58
58
|
|
|
59
|
+
Suffix configuration files with `Config` to enhance visibility and make it easier to identify configuration files at a glance.
|
|
59
60
|
|
|
60
61
|
---
|
|
61
|
-
|
|
62
|
+
|
|
63
|
+
**_By adopting these practices, you create a modular and organized approach to configuration management, making it simpler to locate and manage context-specific settings._**
|
package/src/forms/README.md
CHANGED
|
@@ -3,11 +3,12 @@
|
|
|
3
3
|
The "forms" folder is designed to organize and manage all the necessary forms in our application. Whether it's for managing vehicle-related risks, contact forms, or any other type of form, this folder is intended to centralize the logic and presentation of forms.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
6
|
+
|
|
7
|
+
- [Why Use a "forms" Folder](#folder-organization)
|
|
8
|
+
- [Typical Structure of a "forms" Folder](#structure)
|
|
9
|
+
- [Usage](#usage)
|
|
10
|
+
- [Using React Hook Form](#react-hook-form)
|
|
11
|
+
- [Best Practice](#best-practice)
|
|
11
12
|
|
|
12
13
|
## <span id="folder-organization">Why Use a "forms" Folder?</span>
|
|
13
14
|
|
|
@@ -32,6 +33,7 @@ The structure of a "forms" folder can vary based on our project's needs, but her
|
|
|
32
33
|
│ ├── 📄 ContactForm.tsx
|
|
33
34
|
│ ├── 📄 ContactForm.module.css
|
|
34
35
|
```
|
|
36
|
+
|
|
35
37
|
In this structure, each form, such as "VehicleRiskForm" or "ContactForm," has its own sub-folder containing associated TypeScript and CSS files. This helps maintain a clear organization of our code.
|
|
36
38
|
|
|
37
39
|
## <span id="usage">🧑🏻💻Usage Example</span>
|
|
@@ -45,12 +47,14 @@ export const App = () => {
|
|
|
45
47
|
return (
|
|
46
48
|
<div>
|
|
47
49
|
<VehicleRiskForm />
|
|
48
|
-
|
|
50
|
+
{/* ... other elements of the application */}
|
|
49
51
|
</div>
|
|
50
52
|
);
|
|
51
53
|
};
|
|
52
54
|
```
|
|
55
|
+
|
|
53
56
|
## <span id="react-hook-form">💡 Using React Hook Form</span>
|
|
57
|
+
|
|
54
58
|
This project utilizes [React Hook Form](https://react-hook-form.com/) for handling forms. React Hook Form is a powerful library for managing forms in React applications with a simple and intuitive API.
|
|
55
59
|
|
|
56
60
|
### React Hook Form Overview
|
|
@@ -81,7 +85,7 @@ import { useForm } from 'react-hook-form';
|
|
|
81
85
|
const MyForm = () => {
|
|
82
86
|
const { register, handleSubmit, formState } = useForm();
|
|
83
87
|
|
|
84
|
-
const onSubmit =
|
|
88
|
+
const onSubmit = data => {
|
|
85
89
|
// Handle form submission
|
|
86
90
|
console.log(data);
|
|
87
91
|
};
|
|
@@ -102,30 +106,37 @@ const MyForm = () => {
|
|
|
102
106
|
);
|
|
103
107
|
};
|
|
104
108
|
```
|
|
109
|
+
|
|
105
110
|
In the above example, we use the useForm hook to initialize the form and get the necessary methods (register, handleSubmit, and formState). The onSubmit function is called when the form is submitted, and you can access the form data from the data parameter.
|
|
106
111
|
|
|
107
|
-
|
|
112
|
+
**_By using React Hook Form in this way, we've streamlined the form management process and created a more maintainable and efficient solution for handling forms in our project._**
|
|
108
113
|
|
|
109
114
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
115
|
+
|
|
110
116
|
When working with `React-hook-form`, consider the following best practices to enhance maintainability and organization:
|
|
111
117
|
|
|
112
118
|
#### - Use FormProvider
|
|
113
119
|
|
|
114
|
-
Always use the `FormProvider` provided by `react-hook-form` to manage the form state.
|
|
120
|
+
Always use the `FormProvider` provided by `react-hook-form` to manage the form state.
|
|
115
121
|
|
|
116
122
|
This ensures a centralized state management approach and simplifies form-related operations.
|
|
117
123
|
|
|
118
124
|
#### - Separate Yup Validation Rules
|
|
125
|
+
|
|
119
126
|
If validation rules become extensive, consider separating them into a dedicated file for better organization. This enhances readability and simplifies updates to validation logic.
|
|
120
127
|
|
|
121
128
|
#### - Separate useForm Logic
|
|
129
|
+
|
|
122
130
|
Separate the logic related to `useForm` into a custom hook file, especially if the form logic is complex or if it is shared across multiple components.
|
|
123
131
|
|
|
124
132
|
#### - Separate onSubmit Function
|
|
133
|
+
|
|
125
134
|
If the `onSubmit` function logic is substantial, consider separating it into a dedicated file. This promotes a clean separation of concerns and makes the codebase more modular.
|
|
126
135
|
|
|
127
136
|
#### - Separate Submit Button
|
|
137
|
+
|
|
128
138
|
If needed, separate the submit button into its own file to facilitate easy customization or relocation from the main form component.
|
|
129
139
|
|
|
130
140
|
---
|
|
131
|
-
|
|
141
|
+
|
|
142
|
+
**_By adhering to these best practices, you create a structured and modular approach to form management, ensuring clarity and maintainability in your codebase._**
|
package/src/hooks/README.md
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
|
-
# 📁 hooks
|
|
1
|
+
# 📁 hooks
|
|
2
2
|
|
|
3
3
|
The "hooks" folder is a directory you can create in your React project to group custom hooks you develop. Hooks are special functions introduced in React 16.8, allowing the management of state and lifecycle in functional components.
|
|
4
4
|
|
|
5
|
-
|
|
6
5
|
## 📑 Table of Contents
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
6
|
+
|
|
7
|
+
- [Why Use a "hooks" Folder](#folder-organization)
|
|
8
|
+
- [Usage Example](#usage)
|
|
9
|
+
- [React-Query-Folder](#folder-react-query)
|
|
10
10
|
|
|
11
11
|
## <span id="folder-organization">Why Use a "hooks" Folder?</span>
|
|
12
12
|
|
|
@@ -16,7 +16,6 @@ The "hooks" folder is a directory you can create in your React project to group
|
|
|
16
16
|
|
|
17
17
|
3. **Code Clarity** : Grouping custom hooks in a "hooks" folder simplifies code maintenance and readability, making it easier to locate and understand specific logic.
|
|
18
18
|
|
|
19
|
-
|
|
20
19
|
## <span id="usage">🧑🏻💻 Usage Example</span>
|
|
21
20
|
|
|
22
21
|
Suppose you have a custom hook "useCustomHook1.js" in the "hooks" folder. You can import it and use it in a functional component like this :
|
|
@@ -27,13 +26,10 @@ import { useCustomHook1 } from './hooks/useCustomHook1';
|
|
|
27
26
|
export const MyComponent = () => {
|
|
28
27
|
const customData = useCustomHook1();
|
|
29
28
|
|
|
30
|
-
return
|
|
31
|
-
|
|
32
|
-
{/* Use customData in your component */}
|
|
33
|
-
</div>
|
|
34
|
-
);
|
|
35
|
-
}
|
|
29
|
+
return <div>{/* Use customData in your component */}</div>;
|
|
30
|
+
};
|
|
36
31
|
```
|
|
32
|
+
|
|
37
33
|
## <span id="folder-react-query">"api" Folder for React Query Requests</span>
|
|
38
34
|
|
|
39
35
|
Under the "hooks" folder, we have included a sub-folder "api" specifically designed to handle requests using React Query. This allows for more efficient organization of API requests, isolating them from component logic and leveraging the power of React Query for state and data caching.
|
|
@@ -51,7 +47,6 @@ Each file, such as "useUsers.ts" or "usePosts.ts," contains logic to perform req
|
|
|
51
47
|
|
|
52
48
|
Using React Query for API request management makes data retrieval, caching, and updating easier while reducing code complexity.
|
|
53
49
|
|
|
54
|
-
|
|
55
50
|
### What is React Query?
|
|
56
51
|
|
|
57
52
|
React Query is an open-source JavaScript library that simplifies data management in a React application. It provides a simple and powerful way to handle network requests, data caching, error handling, and more. With React Query, you can significantly improve the development experience of your React applications by managing data efficiently.
|
|
@@ -83,5 +78,6 @@ React Query is an open-source JavaScript library that simplifies data management
|
|
|
83
78
|
- Mutations are easy to define and manage.
|
|
84
79
|
|
|
85
80
|
---
|
|
86
|
-
|
|
87
|
-
|
|
81
|
+
|
|
82
|
+
**_For more information and details, refer to the
|
|
83
|
+
[official React Query documentation.](https://tanstack.com/query/v3/)_**
|
package/src/pages/README.md
CHANGED
|
@@ -1,13 +1,13 @@
|
|
|
1
|
-
# 📁 pages
|
|
1
|
+
# 📁 pages
|
|
2
2
|
|
|
3
3
|
The "pages" folder is designed to contain all the pages of our application. This structure facilitates organization, management, and navigation between the different views of our application. Additionally, if a page contains components related to its structure, we can create sub-folders to maintain order.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
- [Why Use a "pages" Folder](#folder-organization)
|
|
7
|
-
- [Typical Structure of a "pages" Folder](#structure)
|
|
8
|
-
- [Usage Example](#usage)
|
|
9
|
-
- [Best Practice](#best-practice)
|
|
10
6
|
|
|
7
|
+
- [Why Use a "pages" Folder](#folder-organization)
|
|
8
|
+
- [Typical Structure of a "pages" Folder](#structure)
|
|
9
|
+
- [Usage Example](#usage)
|
|
10
|
+
- [Best Practice](#best-practice)
|
|
11
11
|
|
|
12
12
|
## <span id="folder-organization">Why Use a "pages" Folder?</span>
|
|
13
13
|
|
|
@@ -20,6 +20,7 @@ The "pages" folder is designed to contain all the pages of our application. This
|
|
|
20
20
|
## <span id="structure">Typical Structure of a "pages" Folder</span>
|
|
21
21
|
|
|
22
22
|
The structure of a "pages" folder can vary depending on the size of your application, but here is a typical structure you might adopt:
|
|
23
|
+
|
|
23
24
|
```
|
|
24
25
|
📁 Pages
|
|
25
26
|
├── 📁 Home
|
|
@@ -42,6 +43,7 @@ Suppose we have a "UserProfile" page with a complex structure:
|
|
|
42
43
|
├── 📄 UserProfile.tsx
|
|
43
44
|
├── 📄 routes.tsx
|
|
44
45
|
```
|
|
46
|
+
|
|
45
47
|
```javascript
|
|
46
48
|
// index.ts
|
|
47
49
|
export { userProfileRoutes } from './routes';
|
|
@@ -68,21 +70,22 @@ export const UserProfile = () => {
|
|
|
68
70
|
|
|
69
71
|
By using a "pages" folder and the ability to create sub-folders, we effectively organize our pages and their related components for better management of our application.
|
|
70
72
|
|
|
71
|
-
|
|
72
73
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
74
|
+
|
|
73
75
|
When working with page components, it is advisable to follow these best practices to maintain a clean and organized code structure:
|
|
74
76
|
|
|
75
77
|
#### - Minimize Business Logic
|
|
76
78
|
|
|
77
|
-
Limit the inclusion of business logic within page components.
|
|
79
|
+
Limit the inclusion of business logic within page components.
|
|
78
80
|
|
|
79
81
|
Instead, delegate complex business logic to separate utility functions, services, or hooks. This keeps your page components focused on rendering and layout.
|
|
80
82
|
|
|
81
83
|
#### - Data Presence Control
|
|
82
84
|
|
|
83
|
-
Keep the logic within page components to a minimum, focusing primarily on controlling the presence of data.
|
|
85
|
+
Keep the logic within page components to a minimum, focusing primarily on controlling the presence of data.
|
|
84
86
|
|
|
85
87
|
If data is not available or meets certain conditions, consider redirecting to a dedicated error or not-found page.
|
|
86
88
|
|
|
87
89
|
---
|
|
88
|
-
|
|
90
|
+
|
|
91
|
+
**_By adopting these practices, you create page components that are focused on their primary responsibilities, leading to cleaner and more maintainable code._**
|
package/src/providers/README.md
CHANGED
|
@@ -1,12 +1,13 @@
|
|
|
1
|
-
# 📁 providers
|
|
1
|
+
# 📁 providers
|
|
2
2
|
|
|
3
3
|
The "providers" folder is designed to expose service handlers and custom contexts that provide shared functionality across our entire application. It serves as a centralized way to manage services such as authentication, authorization, translation management, and many others.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
6
|
+
|
|
7
|
+
- [Why Use a "providers" Folder?](#folder-organization)
|
|
8
|
+
- [Structure of a "providers" Folder](#structure)
|
|
9
|
+
- [Usage Example](#usage)
|
|
10
|
+
- [Best Practice](#best-practice)
|
|
10
11
|
|
|
11
12
|
## <span id="folder-organization">Why Use a "providers" Folder?</span>
|
|
12
13
|
|
|
@@ -53,31 +54,27 @@ export const AuthProvider = ({ children }) => {
|
|
|
53
54
|
setIsAuthenticated(false);
|
|
54
55
|
};
|
|
55
56
|
|
|
56
|
-
return
|
|
57
|
-
|
|
58
|
-
{children}
|
|
59
|
-
</AuthContext.Provider>
|
|
60
|
-
);
|
|
61
|
-
}
|
|
57
|
+
return <AuthContext.Provider value={{ isAuthenticated, login, logout }}>{children}</AuthContext.Provider>;
|
|
58
|
+
};
|
|
62
59
|
```
|
|
60
|
+
|
|
63
61
|
We can then use this authentication service provider in our components by wrapping our components in the provided context:
|
|
62
|
+
|
|
64
63
|
```javascript
|
|
65
64
|
import { AuthProvider } from '@Front/Providers/AuthProvider';
|
|
66
65
|
|
|
67
66
|
export const App = () => {
|
|
68
|
-
return
|
|
69
|
-
|
|
70
|
-
{/* Vos composants React ici */}
|
|
71
|
-
</AuthProvider>
|
|
72
|
-
);
|
|
73
|
-
}
|
|
67
|
+
return <AuthProvider>{/* Vos composants React ici */}</AuthProvider>;
|
|
68
|
+
};
|
|
74
69
|
```
|
|
70
|
+
|
|
75
71
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
76
72
|
|
|
77
|
-
A good practice is to set up a Higher Order Component (HOC) "withProvider" that allows injecting all providers at
|
|
73
|
+
A good practice is to set up a Higher Order Component (HOC) "withProvider" that allows injecting all providers at
|
|
78
74
|
once.
|
|
79
75
|
|
|
80
76
|
Example:
|
|
77
|
+
|
|
81
78
|
```typescript
|
|
82
79
|
import { ComponentType } from 'react';
|
|
83
80
|
import { QueryClient } from '@tanstack/react-query';
|
|
@@ -110,6 +107,6 @@ import { App } from '@Front/components/App';
|
|
|
110
107
|
const Root = withProvider(App);
|
|
111
108
|
```
|
|
112
109
|
|
|
113
|
-
|
|
110
|
+
---
|
|
114
111
|
|
|
115
|
-
|
|
112
|
+
**_By using a "providers" folder, we centralize the management of services and custom contexts, enhancing code reuse and ease of maintenance._**
|
package/src/routing/README.md
CHANGED
|
@@ -3,10 +3,11 @@
|
|
|
3
3
|
The "routing" folder is responsible for managing navigation within the application. We use the `react-router-dom` library to facilitate route creation and navigation between different views of our application.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
6
|
+
|
|
7
|
+
- [Folder Organization](#folder-organization)
|
|
8
|
+
- [Using `react-router-dom`](#react-router-dom)
|
|
9
|
+
- [Using `appRoutes.ts`](#using-appRoutes)
|
|
10
|
+
- [Learn More](#learn-more)
|
|
10
11
|
|
|
11
12
|
## <span id="folder-organization">Folder Organization</span>
|
|
12
13
|
|
|
@@ -23,15 +24,12 @@ In the "routing" folder, you can find the following files and components:
|
|
|
23
24
|
`react-router-dom` is a library that makes it easy to create routes in a React application. You can import it into the appropriate files to define routes and manage navigation between views. Here's a simple example of its usage:
|
|
24
25
|
|
|
25
26
|
```javascript
|
|
26
|
-
import { createRoot } from
|
|
27
|
-
import {
|
|
28
|
-
createBrowserRouter,
|
|
29
|
-
RouterProvider,
|
|
30
|
-
} from "react-router-dom";
|
|
27
|
+
import { createRoot } from 'react-dom/client';
|
|
28
|
+
import { createBrowserRouter, RouterProvider } from 'react-router-dom';
|
|
31
29
|
|
|
32
30
|
const router = createBrowserRouter([
|
|
33
31
|
{
|
|
34
|
-
path:
|
|
32
|
+
path: '/',
|
|
35
33
|
element: (
|
|
36
34
|
<div>
|
|
37
35
|
<h1>Hello World</h1>
|
|
@@ -40,18 +38,17 @@ const router = createBrowserRouter([
|
|
|
40
38
|
),
|
|
41
39
|
},
|
|
42
40
|
{
|
|
43
|
-
path:
|
|
41
|
+
path: 'about',
|
|
44
42
|
element: <div>About</div>,
|
|
45
43
|
},
|
|
46
44
|
]);
|
|
47
45
|
|
|
48
|
-
createRoot(document.getElementById(
|
|
49
|
-
<RouterProvider router={router} />
|
|
50
|
-
);
|
|
46
|
+
createRoot(document.getElementById('root')).render(<RouterProvider router={router} />);
|
|
51
47
|
```
|
|
52
48
|
|
|
53
49
|
## <span id="using-appRoutes">Using `appRoutes.ts`</span>
|
|
54
|
-
|
|
50
|
+
|
|
51
|
+
How to define a router with parameters ?
|
|
55
52
|
|
|
56
53
|
The simplest way is to write it with the parameters as `react-router` requires, and when using it in a `NavLink` call the `generatPath` function from `react-router`.
|
|
57
54
|
|
|
@@ -63,18 +60,17 @@ export const appRoutes = {
|
|
|
63
60
|
home: '/',
|
|
64
61
|
post: '/post',
|
|
65
62
|
article: '/post/:id',
|
|
66
|
-
}
|
|
63
|
+
};
|
|
67
64
|
// component.tsx
|
|
68
65
|
import { NavLink, generatePath } from 'react-router-dom';
|
|
69
|
-
import { appRoutes
|
|
66
|
+
import { appRoutes } from '@Front/routing/appRoutes';
|
|
70
67
|
export const ComponentName = () => {
|
|
71
|
-
return (
|
|
72
|
-
<NavLink to={generatePath(appRoutes .article, { id: 1 })}>link to article 1</NavLink>
|
|
73
|
-
);
|
|
68
|
+
return <NavLink to={generatePath(appRoutes.article, { id: 1 })}>link to article 1</NavLink>;
|
|
74
69
|
};
|
|
75
70
|
```
|
|
71
|
+
|
|
76
72
|
With the `generatePath` function, it is possible to generate URIs with dynamic parameters.
|
|
77
73
|
|
|
78
|
-
|
|
79
74
|
## <span id="learn-more">🙇 Learn More</span>
|
|
80
|
-
|
|
75
|
+
|
|
76
|
+
- [React Router](https://reactrouter.com/en/main/start/overview)
|
package/src/types/README.md
CHANGED
|
@@ -1,11 +1,12 @@
|
|
|
1
|
-
# 📁 types
|
|
1
|
+
# 📁 types
|
|
2
2
|
|
|
3
3
|
The "types" folder: since we are using TypeScript, this folder is intended to contain custom type definition files that enhance type checking and auto-completion in your code.
|
|
4
4
|
|
|
5
5
|
## 📑 Table of Contents
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
6
|
+
|
|
7
|
+
- [Why use a "types" folder?](#folder-organization)
|
|
8
|
+
- [Structure of a "types" folder](#structure)
|
|
9
|
+
- [Example of usage](#usage)
|
|
9
10
|
|
|
10
11
|
## <span id="folder-organization">Why use a "types" folder?</span>
|
|
11
12
|
|
package/src/ui/README.md
CHANGED
|
@@ -1,14 +1,15 @@
|
|
|
1
|
-
# 📁 ui
|
|
2
|
-
|
|
1
|
+
# 📁 ui
|
|
2
|
+
|
|
3
|
+
The "ui" folder is a directory designed to group and organize reusable components.
|
|
3
4
|
|
|
4
5
|
We follow the concept of Atomic design to structure our components into "atoms," "molecules," "organisms," and "templates," ensuring consistent design and maximum reusability.
|
|
5
6
|
|
|
6
7
|
## 📑 Table of Contents
|
|
7
|
-
- [Why use a "ui" folder with Atomic Design](#folder-organization)
|
|
8
|
-
- [Structure of a "ui" folder according to Atomic Design](#structure)
|
|
9
|
-
- [Usage Example](#usage)
|
|
10
|
-
- [Best Practice](#best-practice)
|
|
11
8
|
|
|
9
|
+
- [Why use a "ui" folder with Atomic Design](#folder-organization)
|
|
10
|
+
- [Structure of a "ui" folder according to Atomic Design](#structure)
|
|
11
|
+
- [Usage Example](#usage)
|
|
12
|
+
- [Best Practice](#best-practice)
|
|
12
13
|
|
|
13
14
|
## <span id="folder-organization">Why use a "ui" folder with Atomic Design?</span>
|
|
14
15
|
|
|
@@ -63,12 +64,12 @@ export const MyComponent = () => {
|
|
|
63
64
|
{/* ... other elements of the application */}
|
|
64
65
|
</div>
|
|
65
66
|
);
|
|
66
|
-
}
|
|
67
|
+
};
|
|
67
68
|
```
|
|
68
69
|
|
|
69
70
|
### Molecule - "SearchBar" Component
|
|
70
|
-
"Molecules" are more complex components that group atoms to form a functional set. In our "ui/molecules" folder, we have the "SearchBar" component that uses the atomic "Button":
|
|
71
71
|
|
|
72
|
+
"Molecules" are more complex components that group atoms to form a functional set. In our "ui/molecules" folder, we have the "SearchBar" component that uses the atomic "Button":
|
|
72
73
|
|
|
73
74
|
```javascript
|
|
74
75
|
import { SearchBar } from '@Front/ui/molecules/SearchBar';
|
|
@@ -77,14 +78,16 @@ export const MyComponent = () => {
|
|
|
77
78
|
return (
|
|
78
79
|
<div>
|
|
79
80
|
<SearchBar placeholder="Rechercher..." />
|
|
80
|
-
|
|
81
|
+
{/* ... other elements of the application */}
|
|
81
82
|
</div>
|
|
82
83
|
);
|
|
83
|
-
}
|
|
84
|
+
};
|
|
84
85
|
```
|
|
86
|
+
|
|
85
87
|
The "SearchBar" component is a molecule because it combines the "Button" atom with other atoms.
|
|
86
88
|
|
|
87
89
|
### Organism - "Header" Component
|
|
90
|
+
|
|
88
91
|
"Organisms" are even more complex components that combine molecules and atoms to create self-contained parts of the UI. In our "ui/organisms" folder, we have the "Header" component that might include the molecular "SearchBar":
|
|
89
92
|
|
|
90
93
|
```javascript
|
|
@@ -94,14 +97,16 @@ export const MyComponent = () => {
|
|
|
94
97
|
return (
|
|
95
98
|
<div>
|
|
96
99
|
<Header />
|
|
97
|
-
|
|
100
|
+
{/* ... other elements of the application */}
|
|
98
101
|
</div>
|
|
99
102
|
);
|
|
100
|
-
}
|
|
103
|
+
};
|
|
101
104
|
```
|
|
105
|
+
|
|
102
106
|
The "Header" component is an organism because it combines the molecular "SearchBar" with other elements to form a self-contained part of the interface.
|
|
103
107
|
|
|
104
108
|
### Templates - "PageTemplate" Component
|
|
109
|
+
|
|
105
110
|
"Templates" are "skeleton" components that define the placement of elements using React's composition ability.
|
|
106
111
|
|
|
107
112
|
In our "ui/templates" folder, we have the "PageTemplate" component that defines the placement of the "topBar," "body," and "footer" to create a complete page:
|
|
@@ -110,32 +115,30 @@ In our "ui/templates" folder, we have the "PageTemplate" component that defines
|
|
|
110
115
|
import PageTemplate from '@Front/ui/templates/PageTemplate';
|
|
111
116
|
|
|
112
117
|
export const MyComponent = () => {
|
|
113
|
-
return
|
|
114
|
-
|
|
115
|
-
topBar={<div>TopBar</div>}
|
|
116
|
-
body={<div>Boby</div>}
|
|
117
|
-
footer={<div>Footer</div>}
|
|
118
|
-
/>
|
|
119
|
-
);
|
|
120
|
-
}
|
|
118
|
+
return <PageTemplate topBar={<div>TopBar</div>} body={<div>Boby</div>} footer={<div>Footer</div>} />;
|
|
119
|
+
};
|
|
121
120
|
```
|
|
121
|
+
|
|
122
122
|
The "PageTemplate" component is a template because it incorporates the "Header" organism and other elements to create a complete page.
|
|
123
123
|
|
|
124
124
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
125
|
+
|
|
125
126
|
When incorporating external component libraries, it is recommended to adhere to the following best practices for the organization of UI components:
|
|
126
127
|
|
|
127
128
|
#### - Export Components via the `ui` Directory
|
|
128
129
|
|
|
129
|
-
Always export UI components from the `ui` directory, even if they are sourced from an external component library.
|
|
130
|
+
Always export UI components from the `ui` directory, even if they are sourced from an external component library.
|
|
130
131
|
|
|
131
132
|
This practice serves as a central point for managing component exports and facilitates handling bugs or breaking changes.
|
|
132
133
|
|
|
133
134
|
#### - Centralized Component Management
|
|
134
|
-
|
|
135
|
+
|
|
136
|
+
By exporting components through the ui directory, you establish a centralized location for managing changes or addressing issues related to external components.
|
|
135
137
|
|
|
136
138
|
In the event of a bug or breaking change, modifications can be made at a single location, preventing the need to update multiple parts of the codebase.
|
|
137
139
|
|
|
138
140
|
This approach contributes to better maintainability and ensures that updates to external components are efficiently managed.
|
|
139
141
|
|
|
140
142
|
---
|
|
141
|
-
|
|
143
|
+
|
|
144
|
+
**_By adopting this practice, you create a clear separation between your custom components and external components, simplifying maintenance and reducing the impact of changes from external dependencies._**
|
package/src/utils/README.md
CHANGED
|
@@ -1,15 +1,17 @@
|
|
|
1
|
-
# 📁 utils
|
|
1
|
+
# 📁 utils
|
|
2
|
+
|
|
2
3
|
The `utils` folder contains reusable utilities and functionalities used across different parts of the application. These utilities are designed to simplify the code, promote reusability, and enhance the maintainability of the project.
|
|
3
4
|
|
|
4
5
|
## 📑 Table of Contents
|
|
5
|
-
|
|
6
|
-
|
|
6
|
+
|
|
7
|
+
- [Usage Example](#usage)
|
|
8
|
+
- [Best Practice](#best-practice)
|
|
7
9
|
|
|
8
10
|
## <span id="usage">🧑🏻💻 Example of usage</span>
|
|
9
11
|
|
|
10
|
-
###
|
|
12
|
+
### `formatDate.ts`
|
|
11
13
|
|
|
12
|
-
The
|
|
14
|
+
The `formatDate.ts` file contains a utility function to consistently format dates throughout the application. You can use it to display dates in various components.
|
|
13
15
|
|
|
14
16
|
Example of usage:
|
|
15
17
|
|
|
@@ -19,7 +21,7 @@ import { formatDate } from '@Front/utils/formatDate';
|
|
|
19
21
|
const formattedDate = formatDate(new Date());
|
|
20
22
|
```
|
|
21
23
|
|
|
22
|
-
###
|
|
24
|
+
### `apiUtils.ts`
|
|
23
25
|
|
|
24
26
|
The `apiUtils.ts` file contains utility functions to simplify API calls. You can find functions to handle HTTP requests, manipulate responses, and manage errors.
|
|
25
27
|
|
|
@@ -32,25 +34,23 @@ async function fetchDataAndHandleError() {
|
|
|
32
34
|
try {
|
|
33
35
|
const data = await fetchData('https://api.example.com/data');
|
|
34
36
|
const processedData = handleResponse(data);
|
|
35
|
-
|
|
36
37
|
} catch (error) {
|
|
37
38
|
console.error('An error occurred while fetching data:', error);
|
|
38
39
|
}
|
|
39
40
|
}
|
|
40
41
|
```
|
|
41
42
|
|
|
42
|
-
|
|
43
43
|
```typescript
|
|
44
44
|
import { formatDate, fetchData, handleResponse } from '@Front/utils';
|
|
45
45
|
// Use the utilities as needed
|
|
46
46
|
```
|
|
47
47
|
|
|
48
|
-
|
|
49
|
-
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
**_By using the "utils" folder, we organize our utilities efficiently for better reuse and simplified management._**
|
|
50
51
|
|
|
51
52
|
## <span id="best-practice">🎖️ Best Practice</span>
|
|
52
53
|
|
|
53
|
-
|
|
54
54
|
When dealing with utility functions, especially those sourced from external libraries like `date-fns`, it is advisable to follow these best practices for maintaining a structured codebase:
|
|
55
55
|
|
|
56
56
|
#### - Export Libraries from the `utils` Directory
|
|
@@ -58,11 +58,13 @@ When dealing with utility functions, especially those sourced from external libr
|
|
|
58
58
|
Always export utility libraries, such as `date-fns` or others, from the `utils` directory. This practice provides a central location for managing library imports and ensures consistent usage throughout the codebase.
|
|
59
59
|
|
|
60
60
|
#### - Centralized Library Management
|
|
61
|
-
|
|
61
|
+
|
|
62
|
+
Exporting libraries through the `utils` directory establishes a centralized point for managing changes or updates to external libraries.
|
|
62
63
|
|
|
63
64
|
In case of updates, bug fixes, or changes in functionality, modifications can be made at a single location, preventing the need to update multiple parts of the codebase.
|
|
64
65
|
|
|
65
66
|
This approach contributes to better maintainability and ensures that updates to external libraries are efficiently handled.
|
|
66
67
|
|
|
67
68
|
---
|
|
68
|
-
|
|
69
|
+
|
|
70
|
+
**_By adhering to this practice, you create a clear separation between custom utility functions and external libraries, making your codebase more organized and reducing the impact of changes from external dependencies._**
|