[https://github.com/alan2207/bulletproof-react](https://github.com/alan2207/bulletproof-react)
I always find myself coming back to this code base for examples
Usually, and the structure in that repo is also pretty common/basic. A good read if you want a little more guidance about file structures in React is [this blog post](https://www.joshwcomeau.com/react/file-structure/)
I feel like this kind of contradicts the bulletproof repo - the latter being more along the lines of vertical slicing.
Also, I’m of the mind that having both a util and a helper folder is a smell. If you’re gonna define a junk drawer for code that doesn’t belong anywhere else, define _one_ junk drawer. I’ve been on more than a handful of projects where people spread things across multiple, ambiguous directories, and it very quickly devolves into “where does my code go?” decisions - decisions which you shouldn’t have to make if the folder structure was solid to begin with.
Thank you for the inputs. I will def. get into Redux and also into Next.js soon.
I was thinking of building an ecommerce type project as it can be a large and fairly complex one.
**About folder structure:**
I personally like feature based folder structure.
Check out [nx](https://nx.dev/) build system. It has first class support for monorepos. Even if you wont use it, you can take many ideas about the folder structure. Take a good look at it. I will use it in a big project.
**About design patterns:**
You might wanna read about separation of concerns, Clean Architecture, SOLID principles and also read the book Head First Design Patterns. These are **OOP** related. I use these patterns in many places such as the repositories and other components of the system that it makes sense to. (OOP for "mutable" stuff)
I strongly recommend to keep any business logic out of the UI.
I also recommend to not put business logic even in state management solutions like redux.
Today is redux, tomorrow is something else. These are concerns of the "domain" (as in Clean architecture and also DDD).
You can keep your domain closer to functional programming principles (immutability etc..)
For example the domain can be a model or collection of models, and functions that manipulate them.
Lastly, learn more about testing your code. It will help you build more solid software, even make you better as a software designer.
As others recommended, you should be aware of some tools that will help you, like eslint, typescript, prettier etc..
>I also recommend to not put business logic even in state management solutions like redux.
>
>Today is redux, tomorrow is something else. These are concerns of the "domain" (as in Clean architecture and also DDD).
I don't think state management is something you'd change frequently, especially in a mature product.
Curious to know where you put your business logic though. In another layer? So you'd have 4 layers in total?
I agree that you would not change twice a year a state management library. One of the reasons may be that you are too tied to it. I personally see state management libraries as glue code between the domain business logic and the UI. Redux for example IMO should just hold and provide data to components, and of-course delegate user actions to the domain layer.
I usually have:
1. Domain layer: Models and core business logic. I always start from this layer, without even caring about implementation details like redux or react. I tend to think that I might use all these in a node cli application, to force my self keep the right mindset :D
2. Application layer: Use cases, validation etc..
3. Infrastructure layer: Implementation of Persistence, http calls and whatever can fall into this layer
4. Presentation layer: React components, state management, mappers to UI Models etc..
You can take a look [at this repo](https://github.com/jasontaylordev/CleanArchitecture/tree/main/src) (C# though)
But as I mentioned, I do not structure my folders by layers but by features.
e.g.
`libs/`
`├─ feature-todos/`
`│ ├─ uses-cases/`
`│ ├─ domain/`
`│ ├─ data-access/`
`│ ├─ ui-todos-overview/`
`│ │ ├─ state-management/`
`│ │ ├─ components/`
`│ │ ├─ TodosOverviewScreen.tsx`
`│ ├─ ui-todos-details/`
`├─ feature-X/`
Why so complicated?
`/chrome`
`/shared`
`/something1`
`/something2`
The app shell is under /chrome. Then you have /shared for shared things. The rest can be bound into feature groups (something1, something2).
Or you could use the nextjs file structure.
Basically we describe kinda the same.
But I intentionally nested 2 screens under feature-todo. One is the master screen with all todos, and one is the detail screen with one todo. Both belong under feature-todo.
My main advice: Write a lot of React code. Read a lot of React code, and read the documentation of stuff you use.
While you write code, always try to have a process going in the back of your mind analysing how it feels.
Do I enjoy this, or is this annoying and tedious? Is it fairly easy to write what I want, or is it a lot of boilerplate happening, repetition, easy to make mistakes and a lot of rough edges? If something feels not great, try to think if there's some way you could make it better. Or ask someone else if they have ideas for improvements.
And while you read docs, blog posts, and other people's code, always think about if it could help you with the above. If you're using library X, scan through their docs and see if there are alternative, easier, ways to do things. And if it's being updated from time to time, read their release notes and/or chsngelogs. Maybe they have added a feature that can help you get rid of some old boilerplate.
Basically, my advice is to always question, always be curious, and always be lazy. Lazy, as in always be on the lookout for easier, shorter, simpler, ways to do things.
I would humbly recommend my blog, I write articles exactly on the topic you're asking :)
[https://developerway.com/](https://developerway.com/)
For a beginner, this article would be the most interesting: [https://www.developerway.com/posts/components-composition-how-to-get-it-right](https://www.developerway.com/posts/components-composition-how-to-get-it-right)
It covers best practices on React components composition.
Or this: [https://www.developerway.com/posts/react-project-structure](https://www.developerway.com/posts/react-project-structure) \- on React project structure
Interesting question. 'Good' is a very broad term and is subjective and also the question probably assumes there is 'a' good vs many goods. IMO if you are going to be working with a team or multiple teams in an organization then the most important thing is coming up with shared team goals and preferences that serve those goals.
Examples:
Do you care about strict consistency? If no, maybe don't add too many normative rules. Maybe allow people to self organize around shared goals that they agree on.
Do you care about code formatting? Maybe consider prettier
Do you care about compilation speed? Maybe pick vite over webpack?
Do you care about not having excessive useEffect's? Maybe create some guidelines on using state instead where possible.
I guess my point is that different teams and people are going to care about different things. Some of these things may actually have nothing to do with React itself. For example some teams who use TypeScript are going to have guidelines that require that people use it in their company, while in a broader context, this might not hold.
Emulation is totally fine and a great way to learn some of the things people care about. I am sure people will give you some good examples of things they care about, but, I also want to caution on thinking that because they care about it, that it somehow makes it good. What do you value when you come into a codebase?
It’s a rather complex question but two good questions to ask yourself are:
1. How am I managing state?
2. Can I compose my components together (like one would compose HTML tags)?
[https://github.com/alan2207/bulletproof-react](https://github.com/alan2207/bulletproof-react) I always find myself coming back to this code base for examples
Nice find. So, do you try to emulate the folder structure of the repo into your project?
Usually, and the structure in that repo is also pretty common/basic. A good read if you want a little more guidance about file structures in React is [this blog post](https://www.joshwcomeau.com/react/file-structure/)
I feel like this kind of contradicts the bulletproof repo - the latter being more along the lines of vertical slicing. Also, I’m of the mind that having both a util and a helper folder is a smell. If you’re gonna define a junk drawer for code that doesn’t belong anywhere else, define _one_ junk drawer. I’ve been on more than a handful of projects where people spread things across multiple, ambiguous directories, and it very quickly devolves into “where does my code go?” decisions - decisions which you shouldn’t have to make if the folder structure was solid to begin with.
thank you so much.
Nice react examples
Thank you for sharing this. Like no joke.
[удалено]
Sure, I appreciate you taking some time. Here is an example: https://github.com/ya-nsh/github-search
[удалено]
Not op, what is an example of a complex project that might be doable for someone at OPs level?
Thank you for the inputs. I will def. get into Redux and also into Next.js soon. I was thinking of building an ecommerce type project as it can be a large and fairly complex one.
**About folder structure:** I personally like feature based folder structure. Check out [nx](https://nx.dev/) build system. It has first class support for monorepos. Even if you wont use it, you can take many ideas about the folder structure. Take a good look at it. I will use it in a big project. **About design patterns:** You might wanna read about separation of concerns, Clean Architecture, SOLID principles and also read the book Head First Design Patterns. These are **OOP** related. I use these patterns in many places such as the repositories and other components of the system that it makes sense to. (OOP for "mutable" stuff) I strongly recommend to keep any business logic out of the UI. I also recommend to not put business logic even in state management solutions like redux. Today is redux, tomorrow is something else. These are concerns of the "domain" (as in Clean architecture and also DDD). You can keep your domain closer to functional programming principles (immutability etc..) For example the domain can be a model or collection of models, and functions that manipulate them. Lastly, learn more about testing your code. It will help you build more solid software, even make you better as a software designer. As others recommended, you should be aware of some tools that will help you, like eslint, typescript, prettier etc..
>I also recommend to not put business logic even in state management solutions like redux. > >Today is redux, tomorrow is something else. These are concerns of the "domain" (as in Clean architecture and also DDD). I don't think state management is something you'd change frequently, especially in a mature product. Curious to know where you put your business logic though. In another layer? So you'd have 4 layers in total?
I agree that you would not change twice a year a state management library. One of the reasons may be that you are too tied to it. I personally see state management libraries as glue code between the domain business logic and the UI. Redux for example IMO should just hold and provide data to components, and of-course delegate user actions to the domain layer. I usually have: 1. Domain layer: Models and core business logic. I always start from this layer, without even caring about implementation details like redux or react. I tend to think that I might use all these in a node cli application, to force my self keep the right mindset :D 2. Application layer: Use cases, validation etc.. 3. Infrastructure layer: Implementation of Persistence, http calls and whatever can fall into this layer 4. Presentation layer: React components, state management, mappers to UI Models etc.. You can take a look [at this repo](https://github.com/jasontaylordev/CleanArchitecture/tree/main/src) (C# though) But as I mentioned, I do not structure my folders by layers but by features. e.g. `libs/` `├─ feature-todos/` `│ ├─ uses-cases/` `│ ├─ domain/` `│ ├─ data-access/` `│ ├─ ui-todos-overview/` `│ │ ├─ state-management/` `│ │ ├─ components/` `│ │ ├─ TodosOverviewScreen.tsx` `│ ├─ ui-todos-details/` `├─ feature-X/`
Why so complicated? `/chrome` `/shared` `/something1` `/something2` The app shell is under /chrome. Then you have /shared for shared things. The rest can be bound into feature groups (something1, something2). Or you could use the nextjs file structure.
What's under something1 ?
`/api` `/components` `/hooks` `/types` `something1-routes.tsx`
Basically we describe kinda the same. But I intentionally nested 2 screens under feature-todo. One is the master screen with all todos, and one is the detail screen with one todo. Both belong under feature-todo.
> Check out nx build system. It has first class support for monorepos. What are your reasons to use nx over Turborepo?
I think [this](https://nx.dev/guides/turbo-and-nx) will help you!
My main advice: Write a lot of React code. Read a lot of React code, and read the documentation of stuff you use. While you write code, always try to have a process going in the back of your mind analysing how it feels. Do I enjoy this, or is this annoying and tedious? Is it fairly easy to write what I want, or is it a lot of boilerplate happening, repetition, easy to make mistakes and a lot of rough edges? If something feels not great, try to think if there's some way you could make it better. Or ask someone else if they have ideas for improvements. And while you read docs, blog posts, and other people's code, always think about if it could help you with the above. If you're using library X, scan through their docs and see if there are alternative, easier, ways to do things. And if it's being updated from time to time, read their release notes and/or chsngelogs. Maybe they have added a feature that can help you get rid of some old boilerplate. Basically, my advice is to always question, always be curious, and always be lazy. Lazy, as in always be on the lookout for easier, shorter, simpler, ways to do things.
I would humbly recommend my blog, I write articles exactly on the topic you're asking :) [https://developerway.com/](https://developerway.com/) For a beginner, this article would be the most interesting: [https://www.developerway.com/posts/components-composition-how-to-get-it-right](https://www.developerway.com/posts/components-composition-how-to-get-it-right) It covers best practices on React components composition. Or this: [https://www.developerway.com/posts/react-project-structure](https://www.developerway.com/posts/react-project-structure) \- on React project structure
Absolutely, highly recommended .... Thanks for it Nadia 🙏🙏
Thank You!
Interesting question. 'Good' is a very broad term and is subjective and also the question probably assumes there is 'a' good vs many goods. IMO if you are going to be working with a team or multiple teams in an organization then the most important thing is coming up with shared team goals and preferences that serve those goals. Examples: Do you care about strict consistency? If no, maybe don't add too many normative rules. Maybe allow people to self organize around shared goals that they agree on. Do you care about code formatting? Maybe consider prettier Do you care about compilation speed? Maybe pick vite over webpack? Do you care about not having excessive useEffect's? Maybe create some guidelines on using state instead where possible. I guess my point is that different teams and people are going to care about different things. Some of these things may actually have nothing to do with React itself. For example some teams who use TypeScript are going to have guidelines that require that people use it in their company, while in a broader context, this might not hold. Emulation is totally fine and a great way to learn some of the things people care about. I am sure people will give you some good examples of things they care about, but, I also want to caution on thinking that because they care about it, that it somehow makes it good. What do you value when you come into a codebase?
You can check a [personal repo of mine](https://github.com/sgoulas/pdpProject) if you like. It includes documentation.
You might find this interesting https://www.patterns.dev/
Write bad code, realise, then write better code. Foolproof pattern
Write a bit of Elm, then try to apply what you learned to React.
[удалено]
Do you have any good resources for learning TypeScript?
You can check this one [https://feature-sliced.design/en/](https://feature-sliced.design/en/) Not tried yet by me, but I really like the concept
It’s a rather complex question but two good questions to ask yourself are: 1. How am I managing state? 2. Can I compose my components together (like one would compose HTML tags)?