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
A simple, scalable, and powerful architecture for building production ready React applications.
@@ -10,30 +10,31 @@ A simple, scalable, and powerful architecture for building production ready Reac
10
10
React is a great tool for building frontend applications. It has a very diverse ecosystem with hundreds of great libraries for literally anything you might need. However, it can be overwhelming to be forced to make so many choices.
11
11
It is also very flexible, you can write React applications in any way you like but that flexibility comes with a cost. Since there is no pre-defined architecture developers can follow, it often leads to messy, inconsistent, or over-complicated codebases.
12
12
13
-
This is an attempt to present the way of creating React applications using the best tools in the ecosystem with a good project structure that scales very well. It is based on the experience of working with many different codebases, and this architecture turns out to be the most effective one.
13
+
This is an attempt to present a way of creating React applications using the best tools in the ecosystem with a good project structure that scales very well. It is based on the experience of working with many different codebases, and this architecture turns out to be the most effective one.
14
14
15
-
The goal of this repo is to serve as a collection of good practices when developing React applications. It is supposed to showcase solving most of the real-world problems of an application in a practical way and help developers writing better applications.
15
+
The goal of this repo is to serve as a collection of resources and good practices when developing React applications. It is supposed to showcase solving most of the real-world problems of an application in a practical way and help developers writing better applications.
16
16
17
17
Feel free to explore the codebase to get the most value out of the repo.
18
18
19
19
#### Disclaimer:
20
20
21
-
This is not supposed to be a template, boilerplate or a framework. It is an opinionated guide that shows how to do some things in a certain way. You are not forced to do everything exactly as it is shown here, decide what works best for you and your team and be consistent with your style.
21
+
This is not supposed to be a template, boilerplate or a framework. It is an opinionated guide that shows how to do some things in a certain way. You are not forced to do everything exactly as it is shown here, decide what works best for you and your team and stay consistent with your style.
Copy file name to clipboardExpand all lines: docs/application-overview.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# The Application Overview
1
+
# 💻 Application Overview
2
2
3
3
The application is pretty simple. Users can create teams where other users can join, and they start discussions on different topics between each other.
Copy file name to clipboardExpand all lines: docs/components-and-styling.md
+19-11Lines changed: 19 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,14 @@
1
-
# Components And Styling
1
+
# 🧱 Components And Styling
2
2
3
3
## Components Best Practices
4
4
5
-
#### Collocate things as close as possible to where it's being used
5
+
#### Colocate things as close as possible to where it's being used
6
6
7
-
Keep components, functions, styles, state, etc. as close as possible to the component where it's being used.
7
+
Keep components, functions, styles, state, etc. as close as possible to the component where it's being used. This will not only make your codebase more readable and easier to understand but it will also improve your application performance since it will reduce redundant re-renders on state updates.
8
8
9
-
#### Avoid nested rendering functions
9
+
#### Avoid large components with nested rendering functions
10
+
11
+
Do not add multiple rendering functions inside your application, this gets out of control pretty quickly. What you should do instead is if there is a piece of UI that can be considered as a unit, is to extract it in a separate component.
10
12
11
13
```javascript
12
14
// this is very difficult to maintain as soon as the component starts growing
@@ -18,7 +20,9 @@ function Component() {
18
20
}
19
21
20
22
// extract it in a separate component
21
-
import { Items } from'components/Items';
23
+
functionItems() {
24
+
return<ul>...</ul>;
25
+
}
22
26
23
27
functionComponent() {
24
28
return (
@@ -31,11 +35,11 @@ function Component() {
31
35
32
36
#### Stay consistent
33
37
34
-
Keep your code style consistent. e.g If you name your components by using pascal case, do it everywhere. If you create components as arrow functions, do it everywhere.
38
+
Keep your code style consistent. e.g If you name your components by using pascal case, do it everywhere. More on this can be found [here](./style-guide.md)
35
39
36
40
#### Limit the number of props a component is accepting as input
37
41
38
-
If your component accepts a lot of props you might consider splitting it into multiple components or use composition via children or slots.
42
+
If your component is accepting too many props you might consider splitting it into multiple components or use the composition technique via children or slots.
39
43
40
44
[Composition Example Code](../src/components/Elements/ConfirmationDialog/ConfirmationDialog.tsx)
41
45
@@ -55,22 +59,24 @@ Every project requires some UI components such as modals, tabs, sidebars, menus,
55
59
56
60
#### Fully featured component libraries:
57
61
58
-
-[Chakra UI](https://chakra-ui.com/) - great library with probably the best developer experience, allows very fast prototyping with decent design defaults. Plenty of components that are very flexible with accessibility already configured out of the box.
62
+
These component libraries come with their components fully styled.
63
+
64
+
-[Chakra UI](https://chakra-ui.com/) - great library with probably the best developer experience, allows very fast prototyping with decent design defaults. Plenty of components that are very customizable and flexible with accessibility already configured out of the box.
59
65
60
66
-[AntD](https://ant.design/) - another great component library that has a lot of different components. Best suitable for creating admin dashboards. However, it might be a bit difficult to change the styles in order to adapt it to a custom design.
61
67
62
68
-[Material UI](https://material-ui.com/) - the most popular component library for React. Has a lot of different components. It might be more suitable for building admin dashboards as it would not be easy to change the components to look like something else than Material Design.
63
69
64
70
#### Headless component libraries:
65
71
66
-
If you have a specific design system from your designer, it might be easier and better solution to go with headless components that come unstyled than to adapt a fully featured library components such as Material UI to your needs. Some good options are:
72
+
These component libraries come with their components unstyled. If you have a specific design system to implement, it might be easier and better solution to go with headless components that come unstyled than to adapt a styled components library such as Material UI to your needs. Some good options are:
[Storybook](https://storybook.js.org/) is a great tool for developing and testing components in isolation. Think of it as a catalogue of all the components your application is using. Very useful especially for larger projects because it helps exploring components.
101
+
[Storybook](https://storybook.js.org/) is a great tool for developing and testing components in isolation. Think of it as a catalogue of all the components your application is using. Very useful for developing and discoverability of components.
94
102
95
103
[Storybook Story Example Code](../src/components/Elements/Button/Button.stories.tsx)
Copy file name to clipboardExpand all lines: docs/error-handling.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,8 @@
1
-
# Error Handling
1
+
# ⚠️ Error Handling
2
2
3
3
### API Errors
4
4
5
-
Set up an interceptor for handling errors. You might want to fire a notification toast to notify users that something went wrong.
5
+
Set up an interceptor for handling errors. You can use it to fire a notification toast to notify users that something went wrong, log out unauthorized users, or send new requests for refreshing tokens.
6
6
7
7
[API Errors Notification Example Code](../src/lib/axios.ts)
Copy file name to clipboardExpand all lines: docs/performance.md
+6-13Lines changed: 6 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
-
# Performance
1
+
# 🚄 Performance
2
2
3
3
### Code Splitting
4
4
5
-
Code splitting is a technique of splitting production js into smaller pieces, thus allowing the application to be only partially downloaded. Any unused code will not be downloaded until it is required by the application.
5
+
Code splitting is a technique of splitting production JavaScript into smaller files, thus allowing the application to be only partially downloaded. Any unused code will not be downloaded until it is required by the application.
6
6
7
-
Most of the time code splitting should be done on the routes level.
7
+
Most of the time code splitting should be done on the routes level, but can also be used for other lazy loaded parts of application.
8
8
9
9
Do not code split everything as it might even worsen your application's performance.
10
10
11
11
[Code Splitting Example Code](../src/routes/index.tsx)
12
12
13
13
### Component and state optimizations
14
14
15
-
- Do not put everything in a single context. That might trigger unnecessary re-renders. Instead split the global state into multiple contexts.
15
+
- Do not put everything in a single state. That might trigger unnecessary re-renders. Instead split the global state into multiple stores according to where it is being used.
16
16
17
17
- Keep the state as close as possible to where it is being used. This will prevent re-rendering components that do not depend on the updated state.
18
18
@@ -36,15 +36,8 @@ Consider lazy loading images that are not in the viewport.
36
36
37
37
Use modern image formats such as WEBP for faster image loading.
38
38
39
+
Use `srcset` to load the most optimal image for the clients screen size.
40
+
39
41
### Web vitals
40
42
41
43
Since Google started taking web vitals in account when indexing websites, you should keep an eye on web vitals scores from [Lighthouse](https://web.dev/measure/) and [Pagespeed Insights](https://developers.google.com/speed/pagespeed/insights/).
42
-
43
-
### Deployment
44
-
45
-
Deploy and serve your application and assets over a CDN. Good options for that are:
0 commit comments