feat: write the first part of the tutorial in English #647
Conversation
✅ Deploy Preview for pr-fsd ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| - `i18n` — locales and internationalization providers | ||
| - `store`\* — store providers | ||
| - `routes` — route constants | ||
| - `env` — environment variables |
There was a problem hiding this comment.
env— environment variables
Imo it should be more familiar config segment. Since we already declared it in other articles and for envs it could be shared/config/env.ts
| - `ui` — the UI kit | ||
| - `api` — the configuration of the API client | ||
| - `i18n` — locales and internationalization providers | ||
| - `store`\* — store providers |
There was a problem hiding this comment.
store* - store providers
I don't get this one. Could you elaborate on this, maybe provide some examples?
Which stores we provide? If we talk about some shared providers like I18nProvider or NotificationProvider or something like that, we probably should leave this providers within their original slices
| - `api` — the configuration of the API client | ||
| - `i18n` — locales and internationalization providers | ||
| - `store`\* — store providers | ||
| - `routes` — route constants |
There was a problem hiding this comment.
routes— route constants
Probably should be shared/router/paths.ts rather specific usecase, so if we need add more things there which are about router it would be clear where to put it
|
|
||
| - `ui` — the UI kit | ||
| - `api` — the configuration of the API client | ||
| - `i18n` — locales and internationalization providers |
|
|
||
| Usually, these two layers are the best places to define your custom segments. Don’t be afraid to create new segments, they don’t cost you anything. For example, your Shared layer could consist of the following segments: | ||
|
|
||
| - `ui` — the UI kit |
There was a problem hiding this comment.
nitpick: Probably should order them in alphabetical order, because they aren't layers, so people don't loose their shit trying to find extensions for ordering or renaming with 01_ui
- api
- config
- i18n
- router
- ui
|
|
||
| *Every element that represents as entity or a feature is placed in the folder of that entity or feature.* | ||
|
|
||
| Once you fully realise that we’re suggesting to have a separate folder for a lousy Delete button, you may rightfully protest, thinking that it is pure overhead with no benefit. And you’re right, it is a lot of overhead. You don’t have to decompose this precisely, though. We believe in what we like to call **Pain-Driven Development** — when you only need to do something if *not doing it* causes you pain. Many small applications don’t really need to have the Features layer, and sometimes they don’t even need the Entities layer. Our application is a prime example of that, however, for the educational purposes of this tutorial, we will go all the way. <!-- TODO: At the end, we will present two versions of the final application: one *fully decomposed* and one *reasonable*. --> |
| 📂 features/ | ||
| 📁 edit-note/ | ||
| 📁 delete-note/ | ||
| 📁 sync-notes/ |
There was a problem hiding this comment.
I didn't find any button or something in images which references sync-notes feature, so I don't get why we need this feature
| 📁 authenticate/ | ||
| ``` | ||
|
|
||
| We grouped some features together (like create and edit, or log in and log out) and omitted some features altogether (reading notes requires no interaction with the app apart from page navigation) because that’s what makes sense from the technical side. |
There was a problem hiding this comment.
nit: Technically we didn't group them, we merge them into one feature called auth/authenticate * (at least I perceived it in that way)
Grouping is about new folder without reuse code
Probably you mean this
- authenticate
- sign-out or logout
- sign-in
instead of (its not that I against of this approach, but wording could be more clear)
- authenticate
- model
- sign-in.model.ts
- sign-out.model.ts
- ui
- sign-in-form
- sign-out-button
| - Model segment — storage of the fetched notes for app-wide access | ||
| - Features | ||
| - Authenticate slice | ||
| - UI segment — the button to sign in that displays the current user |
There was a problem hiding this comment.
you missed here mention about sign-in form
| - Entities | ||
| - Note slice | ||
| - UI segment — the appearance of a note card | ||
| - API segment — query for a list of notes from the backend | ||
| - Model segment — storage of the fetched notes for app-wide access |
There was a problem hiding this comment.
Probably should contain entity user/session so it would be clear from where we read user name Sign-out (Lev)
|
This tutorial is no good as well |
Background
Continuation of #574
Changelog
Replaced the English tutorial with part 1 of the new one. It should be better than the old one even when only consisting of one part.