2
2
3
3
PotLock application.
4
4
5
- You can access BOS Potlock Version using one of the environments below:
5
+ You can access BOS PotLock version using one of the environments below:
6
6
7
7
- [ Production] ( https://app.potlock.org/ )
8
8
- [ Staging] ( https://app.potlock.org/staging.potlock.near/widget/IndexLoader )
9
9
10
- ## Getting Started
10
+ ## Development
11
+
12
+ ### Getting Started
11
13
12
14
``` bash
13
15
# using the right node version
14
16
nvm use;
15
17
# enable Yarn support
16
18
corepack enable ;
17
- # install dependencies
18
- yarn;
19
19
# create config for environment variables
20
- cp .env.example .env.local
20
+ cp .env.example .env.local;
21
21
# if required, edit .env.local
22
- # then run the development server
22
+ # then run the development server ( dependencies will be installed automatically )
23
23
yarn dev
24
24
```
25
25
26
26
Open [ http://localhost:3000 ] ( http://localhost:3000 ) in your browser.
27
27
28
- ## DJango Indexer API
28
+ ### DJango Indexer API
29
29
30
- This project is using a indexer service. You can access its docs here: < https://github.com/PotLock/django-indexer?tab=readme-ov-file#api-endpoints >
30
+ This project is using an indexer service.
31
+ You can access its docs here: < https://github.com/PotLock/django-indexer?tab=readme-ov-file#api-endpoints >
31
32
32
33
** URI** : ` http://ec2-100-27-57-47.compute-1.amazonaws.com/api/v1 `
33
34
34
- ## Project Structure
35
+ ### Project Structure
35
36
36
- Maintains explicit separation between abstract and business-logic-heavy parts of the codebase.
37
- This structure offers a highly modular approach, defining clear boundaries for different aspects of the application within each module:
37
+ Provides explicit separation between abstract and business-logic-heavy parts of the codebase,
38
+ for which it offers a highly modular approach, defining clear boundaries for different
39
+ aspects of the application within each module:
38
40
39
41
``` sh
42
+
40
43
[ src/ ]
41
44
│
42
- ├── [ app ] < --- # Entry point of the application. Follows Nextjs App routing specification ( see link 1. )
45
+ ├── [ app ] < --- # Entry point of the application.
46
+ │ │ # Follows Nextjs App routing specification ( see link 1. )
43
47
│ │
44
48
│ ...
45
49
│ │
46
- │ └── [ _store ] < --- # Application state root. Uses Rematch state management library, based on Redux
47
- │
50
+ │ └── [ _store ] < --- # Application state root.
51
+ │ # Uses Rematch state management library, based on Redux.
48
52
│
49
53
│
50
54
│
51
55
│
52
- ├── [ common ] < --- # Low-level foundation of the app, containing endpoint bindings, utility libraries,
53
- │ │ # reusable primitives, and assets, used in layouts and business logic across the codebase.
54
- │ │ # MUST NOT itself contain business logic. AKA "shared" ( see link 2. )
56
+ ├── [ common ] < --- # Low-level foundation of the app, containing endpoint bindings,
57
+ │ │ # utility libraries, reusable primitives, and assets, used in layouts and
58
+ │ │ # business logic across the codebase. MUST NOT contain business logic by itself.
59
+ │ │ # AKA "shared" ( see link 2. )
55
60
│ │
56
61
│ ├── constants.ts < --- # Static reusable values, e.g.
57
62
│ │ export const DEFAULT_NETWORK = " testnet"
@@ -72,14 +77,14 @@ This structure offers a highly modular approach, defining clear boundaries for d
72
77
│ │
73
78
│ ├── [ components ] < --- # React components implementing UI design primitives
74
79
│ │
75
- │ └── [ utils ] < --- # UI-specific utilities, like DOM manipulations or TailwindCSS class transformers
80
+ │ └── [ utils ] < --- # UI-specific utilities, like DOM manipulations
81
+ │ # or TailwindCSS class transformers
76
82
│
77
83
│
78
84
│
79
85
│
80
- │
81
- └── [ modules ] < --- # Business logic units broken down into categories.
82
- │ # Simply put, this is a collection of directories that contain code implementing specific
86
+ └── [ modules ] < --- # Business logic units broken down into categories. Simply put, this is
87
+ │ # a collection of directories that contain code implementing specific
83
88
│ # groups of app use cases and are named after functionalities they provide.
84
89
│
85
90
...
@@ -93,7 +98,7 @@ This structure offers a highly modular approach, defining clear boundaries for d
93
98
│ ├── constants.ts < --- # Module-specific static reusable values, e.g.
94
99
│ │ export const POTLOCK_REGISTRY_LIST_ID = 1
95
100
│ │
96
- │ ├── models.ts < --- # Feature state definitions ( See link 2 . )
101
+ │ ├── models.ts < --- # Feature state definitions ( See link 3 . )
97
102
│ │ # If this file grows over 300 LoC, consider turning it into a directory
98
103
│ │ # with the same name by applying code-splitting techniques.
99
104
│ │
@@ -112,8 +117,89 @@ This structure offers a highly modular approach, defining clear boundaries for d
112
117
113
118
```
114
119
115
- ### Links
120
+ #### Links
116
121
117
122
1 . [ Nextjs Routing] ( https://nextjs.org/docs/app/building-your-application/routing )
118
123
2 . [ Shared layer from Feature-Sliced Design methodology] ( https://feature-sliced.design/docs/reference/layers#shared )
119
124
3 . [ Rematch models] ( https://rematchjs.org/docs/api-reference/models )
125
+
126
+ ### Testing
127
+
128
+ We use Vitest testing framework coupled with React Testing Library to specifically target UI.
129
+
130
+ For details, please refer to the corresponding documentation resources:
131
+
132
+ - [ Vitest API reference] ( https://vitest.dev/api/ )
133
+ - [ React Testing Library guideline] ( https://testing-library.com/docs/react-testing-library/example-intro )
134
+
135
+ #### Commands
136
+
137
+ Execute all unit tests:
138
+
139
+ ``` bash
140
+ yarn test:unit
141
+ ```
142
+
143
+ Run dev server for unit tests:
144
+
145
+ ``` bash
146
+ yarn dev:test
147
+ ```
148
+
149
+ #### File colocation
150
+
151
+ The project convention implies keeping the test scenarios alongside the code they're meant for
152
+ ( See examples below ).
153
+
154
+ ##### Pages
155
+
156
+ Tests for each page must be placed in ` tests.tsx `
157
+ within the same directory where ` page.tsx ` is located:
158
+
159
+ ``` bash
160
+
161
+ ─── [ app ]
162
+ │
163
+ ├── page.tsx < --- # Homepage ( URL "/" )
164
+ │
165
+ ├── tests.tsx < --- # Tests for Homepage
166
+ │
167
+ ├── [ pots ]
168
+ │ │
169
+ │ ├── page.tsx < --- # Pots page ( URL "/pots" )
170
+ │ │
171
+ │ └── tests.tsx < --- # Tests for Pots page
172
+ │
173
+ └── [ users ]
174
+ │
175
+ └── [ [userId] ]
176
+ │
177
+ ├── page.tsx < --- # User page ( e.g. "/users/builder.near" )
178
+ │
179
+ └── tests.tsx < --- # Tests for User page
180
+
181
+ ```
182
+
183
+ ##### Modules
184
+
185
+ For modules, we target specific implementation details:
186
+
187
+ ``` bash
188
+
189
+ ─── [ modules ]
190
+ │
191
+ └── [ profile ] < --- # Profile module
192
+ │
193
+ ├── [ components ]
194
+ │ │
195
+ │ ├── ProfileCard.tsx < --- # Profile card component
196
+ │ │
197
+ │ └── ProfileCard.test.tsx < --- # Tests for profile card component
198
+ │
199
+ └── [ utils ]
200
+ │
201
+ ├── validation.ts < --- # Profile validation functions
202
+ │
203
+ └── validation.test.ts < --- # Profile validation tests
204
+
205
+ ```
0 commit comments