You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/project-structure.md
+11-5Lines changed: 11 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,9 @@ Most of the code lives in the `src` folder and looks something like this:
5
5
```sh
6
6
src
7
7
|
8
-
+-- app # application level containing
8
+
+-- app # application layer containing:
9
9
||
10
-
| +-- routes # application routes
10
+
| +-- routes # application routes / can also be called pages
11
11
+-- app.tsx # main application component
12
12
+-- app-provider # application provider that wraps the entire application with global providers
13
13
+-- assets # assets folder can contain all the static files such as images, fonts, etc.
@@ -57,7 +57,7 @@ NOTE: You don't need all of these folders for every feature. Only include the on
57
57
58
58
In the past, it was recommended to use barrel files to export all the files from a feature. However, it can cause issues for Vite to do tree shaking and can lead to performance issues. Therefore, it is recommended to import the files directly.
59
59
60
-
It might be a bad idea to import across the features. Instead, compose different features at the application level. This way, you can ensure that each feature is independent and can be easily moved or removed without affecting other parts of the application and also makes the codebase less convoluted.
60
+
It might be not be a good idea to import across the features. Instead, compose different features at the application level. This way, you can ensure that each feature is independent which makes the codebase less convoluted.
61
61
62
62
To forbid cross-feature imports, you can use ESLint:
63
63
@@ -67,7 +67,7 @@ To forbid cross-feature imports, you can use ESLint:
67
67
{
68
68
zones: [
69
69
// disables cross-feature imports:
70
-
// eg. src/features/auth should not import from src/features/comments, etc.
70
+
// eg. src/features/discussions should not import from src/features/comments, etc.
71
71
{
72
72
target:'./src/features/auth',
73
73
from:'./src/features',
@@ -100,7 +100,13 @@ To forbid cross-feature imports, you can use ESLint:
100
100
],
101
101
```
102
102
103
-
You might also want to enforce unidirectional codebase architecture. This means that the code should flow in one direction, from shared parts of the code to the application (shared -> features -> app). This is a good practice to follow as it makes the codebase more predictable and easier to understand. To enforce this, you can use ESLint:
103
+
You might also want to enforce unidirectional codebase architecture. This means that the code should flow in one direction, from shared parts of the code to the application (shared -> features -> app). This is a good practice to follow as it makes the codebase more predictable and easier to understand.
As you can see, the shared parts can be used by any part of the codebase, but the features can only import from shared parts and the app can import from features and shared parts.
Copy file name to clipboardExpand all lines: docs/state-management.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Component state is specific to individual components and should not be shared gl
9
9
-[useState](https://react.dev/reference/react/useState) - for simpler states that are independent
10
10
-[useReducer](https://react.dev/reference/react/useReducer) - for more complex states where on a single action you want to update several pieces of state
11
11
12
-
[Component State Example Code](../src/features/auth/components/register-form.tsx)
12
+
[Component State Example Code](../src/components/layouts/dashboard-layout.tsx)
0 commit comments