@pplancq/react-template 1.6.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 CHANGED
@@ -2,5 +2,6 @@ module.exports = {
2
2
  '*.{js,jsx,ts,tsx}': 'eslint --fix',
3
3
  '*.{ts,tsx}': 'tsc-files --noEmit',
4
4
  '*.{scss,css}': 'stylelint --fix',
5
+ '*.!(js|jsx|ts|tsx|scss|css)': 'prettier --write --ignore-unknown',
5
6
  '(package|package-lock).json': 'npm run package:check',
6
7
  };
package/CHANGELOG.md CHANGED
@@ -1,3 +1,22 @@
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
+
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)
9
+
10
+ ### Features
11
+
12
+ * **react-template:** bump vitest from 1.6.0 to 2.0.5 ([4c129d3](https://github.com/pplancq/dev-tools/commit/4c129d303cc27d5b73dbbdb9710f2ad64745c1cf))
13
+
14
+
15
+ ### Dependencies
16
+
17
+ * **@pplancq/postcss-config:** upgraded to 2.0.0
18
+ * **@pplancq/webpack-config:** upgraded to 1.5.0
19
+
1
20
  ## @pplancq/react-template [1.6.0](https://github.com/pplancq/dev-tools/compare/@pplancq/react-template@1.5.1...@pplancq/react-template@1.6.0) (2024-06-05)
2
21
 
3
22
  ### 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.6.0",
3
+ "version": "1.8.0",
4
4
  "license": "MIT",
5
5
  "description": "react template",
6
6
  "author": "pplancq <paul.plancq@outlook.fr>",
@@ -13,14 +13,16 @@
13
13
  "start": "webpack serve",
14
14
  "start:mock": "webpack serve --env FRONT_MOCK_ENABLE=true",
15
15
  "build": "webpack --mode production",
16
- "test": "vitest",
17
- "test:ci": "vitest run --coverage",
18
- "lint": "concurrently --prefix-colors auto \"npm:eslint\" \"npm:tsc\" \"npm:stylelint\"",
19
- "eslint": "eslint src --ext js,jsx,ts,tsx",
20
- "eslint:fix": "eslint src --ext js,jsx,ts,tsx --fix",
21
- "stylelint": "stylelint \"src/**/*.{scss,css}\"",
22
- "stylelint:fix": "stylelint \"src**/*.{scss,css}\" --fix",
23
- "tsc": "tsc --noEmit",
16
+ "test": "vitest run",
17
+ "test:watch": "vitest",
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",
@@ -34,17 +36,17 @@
34
36
  "template"
35
37
  ],
36
38
  "dependencies": {
37
- "@hookform/resolvers": "^3.4.2",
38
- "@tanstack/react-query": "^5.40.0",
39
- "@tanstack/react-query-devtools": "^5.40.0",
39
+ "@hookform/resolvers": "^3.9.0",
40
+ "@tanstack/react-query": "^5.51.23",
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.51.5",
43
- "react-router-dom": "^6.23.1",
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": {
47
- "@commitlint/cli": "^19.3.0",
49
+ "@commitlint/cli": "^19.4.0",
48
50
  "@pplancq/babel-config": "*",
49
51
  "@pplancq/commitlint-config": "*",
50
52
  "@pplancq/eslint-config": "*",
@@ -52,31 +54,31 @@
52
54
  "@pplancq/prettier-config": "*",
53
55
  "@pplancq/stylelint-config": "*",
54
56
  "@pplancq/webpack-config": "*",
55
- "@testing-library/jest-dom": "^6.4.5",
56
- "@testing-library/react": "^15.0.7",
57
+ "@testing-library/jest-dom": "^6.5.0",
58
+ "@testing-library/react": "^16.0.0",
57
59
  "@testing-library/user-event": "^14.5.1",
58
- "@types/react": "^18.3.3",
60
+ "@types/react": "^18.3.4",
59
61
  "@types/react-dom": "^18.3.0",
60
- "@vitejs/plugin-react": "^4.3.0",
61
- "@vitest/coverage-v8": "^1.6.0",
62
+ "@vitejs/plugin-react": "^4.3.1",
63
+ "@vitest/coverage-v8": "^2.0.5",
62
64
  "concurrently": "^8.2.2",
63
65
  "eslint": "^8.57.0",
64
- "eslint-plugin-prettier": "^5.1.3",
65
- "husky": "^9.0.11",
66
- "jsdom": "^24.1.0",
67
- "lint-staged": "^15.2.5",
68
- "msw": "^2.3.1",
69
- "prettier": "^3.3.0",
70
- "stylelint": "^16.6.1",
71
- "stylelint-prettier": "^5.0.0",
66
+ "eslint-plugin-prettier": "^5.2.1",
67
+ "husky": "^9.1.5",
68
+ "jsdom": "^25.0.0",
69
+ "lint-staged": "^15.2.9",
70
+ "msw": "^2.3.5",
71
+ "prettier": "^3.3.3",
72
+ "stylelint": "^16.8.2",
73
+ "stylelint-prettier": "^5.0.2",
72
74
  "tsc-files": "^1.1.4",
73
- "typescript": "^5.4.5",
75
+ "typescript": "^5.5.4",
74
76
  "vite-plugin-svgr": "^4.2.0",
75
- "vite-tsconfig-paths": "^4.3.2",
76
- "vitest": "^1.0.4",
77
+ "vite-tsconfig-paths": "^5.0.1",
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.91.0",
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
- <!DOCTYPE html>
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>
@@ -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` and `data.ts` to handle these respective calls.
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.
@@ -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
- - [Why Use an "assets" Folder](#folder-organization)
7
- - [Usage Example](#usage)
8
- - [Best Practice](#best-practice)
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
- Define all global CSS rules, such as resets, fonts, and general styling, in a centralized stylesheet (in the css folder under the assets ).
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
- This helps prevent unintentional styling conflicts and promotes a modular approach to styling.
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._**
@@ -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
  ```
@@ -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
- - [Folder Organization](#folder-organization)
7
- - [Content Example](#content-example)
8
- - [Usage](#usage)
9
- - [Best Practice](#best-practice)
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` for configurations related to API calls, `appConfig.ts` for general application settings, `queryClientConfig.ts` for react-query-related configuration, etc.
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
- Separate configuration files based on different contexts, such as API configurations, QueryClient configurations, translations, etc.
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
- ***By adopting these practices, you create a modular and organized approach to configuration management, making it simpler to locate and manage context-specific settings.***
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._**
@@ -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
- - [Why Use a "forms" Folder](#folder-organization)
7
- - [Typical Structure of a "forms" Folder](#structure)
8
- - [Usage](#usage)
9
- - [Using React Hook Form](#react-hook-form)
10
- - [Best Practice](#best-practice)
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
- {/* ... other elements of the application */}
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 = (data) => {
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
- ***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.***
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
- ***By adhering to these best practices, you create a structured and modular approach to form management, ensuring clarity and maintainability in your codebase.***
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._**
@@ -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
- - [Why Use a "hooks" Folder](#folder-organization)
8
- - [Usage Example](#usage)
9
- - [React-Query-Folder](#folder-react-query)
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
- <div>
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
- ***For more information and details, refer to the
87
- [official React Query documentation.](https://tanstack.com/query/v3/)***
81
+
82
+ **_For more information and details, refer to the
83
+ [official React Query documentation.](https://tanstack.com/query/v3/)_**
@@ -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
- ***By adopting these practices, you create page components that are focused on their primary responsibilities, leading to cleaner and more maintainable code.***
90
+
91
+ **_By adopting these practices, you create page components that are focused on their primary responsibilities, leading to cleaner and more maintainable code._**
@@ -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
- - [Why Use a "providers" Folder?](#folder-organization)
7
- - [Structure of a "providers" Folder](#structure)
8
- - [Usage Example](#usage)
9
- - [Best Practice](#best-practice)
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
- <AuthContext.Provider value={{ isAuthenticated, login, logout }}>
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
- <AuthProvider>
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
- ***By using a "providers" folder, we centralize the management of services and custom contexts, enhancing code reuse and ease of maintenance.***
112
+ **_By using a "providers" folder, we centralize the management of services and custom contexts, enhancing code reuse and ease of maintenance._**
@@ -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
- - [Folder Organization](#folder-organization)
7
- - [Using `react-router-dom`](#react-router-dom)
8
- - [Using `appRoutes.ts`](#using-appRoutes)
9
- - [Learn More](#learn-more)
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 "react-dom/client";
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: "about",
41
+ path: 'about',
44
42
  element: <div>About</div>,
45
43
  },
46
44
  ]);
47
45
 
48
- createRoot(document.getElementById("root")).render(
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
- How to define a router with parameters ?
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 } from '@Front/routing/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
- - [React Router](https://reactrouter.com/en/main/start/overview)
75
+
76
+ - [React Router](https://reactrouter.com/en/main/start/overview)
@@ -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
- - [Why use a "types" folder?](#folder-organization)
7
- - [Structure of a "types" folder](#structure)
8
- - [Example of usage](#usage)
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
- The "ui" folder is a directory designed to group and organize reusable components.
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
- {/* ... other elements of the application */}
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
- {/* ... other elements of the application */}
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
- <PageTemplate
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
- By exporting components through the ui directory, you establish a centralized location for managing changes or addressing issues related to external components.
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
- ***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.***
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._**
@@ -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
- - [Usage Example](#usage)
6
- - [Best Practice](#best-practice)
6
+
7
+ - [Usage Example](#usage)
8
+ - [Best Practice](#best-practice)
7
9
 
8
10
  ## <span id="usage">🧑🏻‍💻 Example of usage</span>
9
11
 
10
- ### `formatDate.ts`
12
+ ### `formatDate.ts`
11
13
 
12
- 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.
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
- ### `apiUtils.ts`
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
- ***By using the "utils" folder, we organize our utilities efficiently for better reuse and simplified management.***
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
- Exporting libraries through the `utils` directory establishes a centralized point for managing changes or updates to external libraries.
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
- ***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.***
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._**
package/vitest.config.mts CHANGED
@@ -1,3 +1,4 @@
1
+ /* eslint-disable import/no-extraneous-dependencies */
1
2
  import react from '@vitejs/plugin-react';
2
3
  import { resolve } from 'path';
3
4
  import { loadEnv } from 'vite';
@@ -5,6 +6,7 @@ import svgr from 'vite-plugin-svgr';
5
6
  import viteTsconfigPaths from 'vite-tsconfig-paths';
6
7
  import { defineConfig } from 'vitest/config';
7
8
 
9
+ // eslint-disable-next-line import/no-default-export
8
10
  export default defineConfig(({ mode }) => {
9
11
  const env = loadEnv(mode, process.cwd(), '');
10
12
 
@@ -14,7 +16,7 @@ export default defineConfig(({ mode }) => {
14
16
  viteTsconfigPaths({
15
17
  projects: [resolve(__dirname, './tsconfig.test.json')],
16
18
  }),
17
- svgr()
19
+ svgr(),
18
20
  ],
19
21
  envPrefix: env.ENV_PREFIX ?? 'FRONT_',
20
22
  test: {
@@ -26,7 +28,7 @@ export default defineConfig(({ mode }) => {
26
28
  reporters: ['basic', 'junit', 'vitest-sonar-reporter'],
27
29
  outputFile: {
28
30
  'vitest-sonar-reporter': 'sonar-report.xml',
29
- 'junit': 'junit-report.xml',
31
+ junit: 'junit-report.xml',
30
32
  },
31
33
  include: ['src/**/*.(spec|test|steps).[jt]s?(x)'],
32
34
  poolOptions: {
@@ -36,6 +38,7 @@ export default defineConfig(({ mode }) => {
36
38
  },
37
39
  },
38
40
  coverage: {
41
+ enabled: env.CI,
39
42
  reporter: ['lcov', 'json', 'html', 'text', 'cobertura'],
40
43
  provider: 'v8',
41
44
  lines: 80,