Can't believe this isn't more documented on the web yet. People need to start talking more about what it looks like to build projects with enterprise level structure :D Great Stuff!
This was my very first concern learning how to make simple apps back in college. Nobody was really able to answer my question and just like you said, it's not documented at all online! It would have sped up my learning so much.
@@pleasejustletmebeanonymous6510 while that may be true, just seeing one example that's thought out and explained is a major help in getting my head wrapped around the bigger picture of the application. It can then help me better understand other projects, regardless of structure. But now I wonder if many projects will have to be re-written with the help of AI lol
@@pleasejustletmebeanonymous6510 Agreed, but I would like to add that it is the responsibility of leadership and management to work on this, and the devs should be vocal about it.
This is what I do as a front-end specialist: - domain: This is a suggestive/temporary name that represents the only(and the main) module that the application has. If/when the application scales, new folders like this would be created for each domain, so we could have 'users' (for example) and its components, pages, icons, hooks, etc., and another folder called 'payment' and its components, pages, icons, hooks, etc. It is important to highlight that an application domain can have multiple pages and that those pages will be sub-routes, for example, users/registration, users/permissions, etc - shared: A folder represents code that is used/reused without being tied to any application's rule. This folder is not called 'common' because it does not just hold common code but also has the potential to become a private/internal library - other projects within the same company could be using a versioned flavor of this folder. Regarding the project's structure/organization, this folder is also a container for another folder, so it will hold shared components, models, icons, hooks, etc. So... Pages (and page folders) will not be treated as containers for multiple pieces of code, as this only happens with domain and shared folders. Pages will be treated as normal components, with the difference that they will be rendered when we reach certain routes. That said, components and pages will use the same naming conventions, coding patterns, testing approach, etc
As far as my experience allows me to say, I can add the following: 1. the 'junior approach' becomes very problematic as soon as a second programmer start to work on that code. So I would directly jumpt to the second approach 2. The third approach is very near to the hexagonal architecture, which facilitates the ownership of each programmer in a domain, reduce the risk of conflict and makes it cheaper to transfer the domain to another service. At this point, typescript should be used, and a "dto" folder for types should also be added.
One big addtion to consider is a template/transform file structure for API calls. When dealing with mock data and mocking all API functions, having a specific data/API/Mock folder system is super helpful Our rule of thumb is a file per URI so /v1/files GET/POST/PUT would all get its own template transform file (turn BE values to FE values and the reverse), a mock API responce File, and the accociated tests for them. That kind of breakdown makes dealing with the API layer much more tidey.
I did this project without watching it first. I used "startsWith" method instead of "includes" . It sorts words much logically 🙂 Thank you for teaching useful projects
as always, so clear and well explained. I suggest you to share an actual project (if you can of course) for each type of structure. It would be amazing, I guess a lot of people likes to have an exemple to work with as I do. anyway, just keep going you are amazing ! ha and thanks for the free course :)
Hi, Kyle! I heard you said once that, before getting your first job, you had researched the companies for which you were going to apply before actually applying to their job offers, so that you could focus your efforts, instead of sending tons of applications, and also make sure you'd end up in a work environment you'd like, and all that payed off in the end. Could you please share how you got informed about the companies' cultures and how did you know they would be a good fit?
This was extremely helpful! I'm building a rather large project and couldn't think of a clever way to structure my files. As I'm still at the start it'll be quite easy to apply your method of folder structuring.
One thing i usually do is create a folder for each component. the folder contains an index.ts and a "ComponentName.ts" (or .js if you use that), the component is exported as default from the index.ts, this way, you have a folder which encapsulated everything related to that specific component (styles, tests, logics, etc..) AND when importing you only have to reference the folder instead of the folder and the component because it's exported from the index.ts, (eg import ComponentFoo from "components/ComponentsFoo" instead of "components/ComponentsBar/ComponentsBar") best of both worlds. I already hear the question "Why only export from index.ts and not just place the entire component there?" ---> because if you keep it separated you can still easily search for components in a growing code-base.
Thanks for this. I already had a pages , components and a sub-components inside components. I just added a data folder and moved my data into there. I created a utils folder but I don't have anything in there yet.
Instead of having those global folders, you could create a "global" or "shared" folder under "features" and get rid of that duplicate folder structure. This way you have src > features > [authentication, projects, settings, shared, todos] > [assets, components, context, data, hooks, ...]
Yes, been using folder-by-feature with my team for the past 3-4 years. Scales really well, because ourcode base has around 8-9 people actively commiting to it. (It's a monorepo too)
Thanks so much for making this video! I've been searching for a breakdown like this for some time now, and this will help a lot with structuring my NPM projects' folders.
@@nathanr6479 the package.json is your blueprint, your package-lock.json is your actual installed modules and libs would contain the code you write for them, you don't always just import a module into your components.
It always weirds me out the tiny amount of talk on this topic, for me one of the most difficult things in a react project (or any project, really) is the folder structure. A great work as always Kyle
I have looked for 6 days how to organize project structure properly for full-stack app I have learned smth but there are too many examples so I got confused. Thank You! 🚀
My team and I essentially use this same structure for our Big Pharma clients like Pfizer and Novartis. A little 2 cents about what we do - we first take the src folder and put a front-end & back-end folder in there. With the new server components coming out, we thing its a good idea to begin adopting this now. Then in each of those folders we have a "common" folder - which is obviously components that have the potential to be used everywhere, but being explicit makes life easier yall!! lol then we have a breakdown very similar to what is in this video except the frontend folder handles all the static assets, and no "services" since we have a server, api, middleware, auth, etc. folders in the main backend folder and the FE folder again has almost exact structures shown here - hope someone gets something cool from my ramble lol
The only problem I have with React is the freedom they give u to decide your project structure. I love React a lot but I normally choose Angular just because it structures your project for you.
(More advanced) I would move root level features, services, hooks and other stuff thats esssential for the app to function to a new folder called 'core' for easier folder structure. I would also add 'store' folders to features. I would also add the folder 'domain'. I would use this with domain driven development. I would put pages components, hooks, and services there too. I would put all http-based services in an seperate folder called 'http' too. This is for being as clear of whats going on.
I use like this: core(auth, interceptors, etc), shared(reusable components), features(pages and related features to that page), layout(header, footer, etc), helpers(helpers functions, constants)
Encapsulating everything in your index.js file is an anti pattern and will have issues with tree shaking code you may not be using, or when dynamically importing. Instead, you can use a ts/js config to set paths to make imports without awkward ../../. Also, I’d avoid any default exports when writing application code as it can lead to team members naming things confusingly.
Depends on the module pattern. If you use ESM and export (not export default) and import (not import * as) this is not a problem. Most tree shaking nowadays does static analysis to both find out what you import and their dependencies and only include that in a build. However, consolidating exports in an index file has the disadvantage that it can create circular dependencies (if you import it from re-exported files), makes dynamic imports import unnecessary files and make builds slower due to this optimization path. It's fine to provide a library which exports public APIs (i.e. a ui library that exports components that should be consumed by apps), but internally it can create a headache.
I appreciate your videos. I love watching them. I've been banging my head with good folder structure, so thank you for this. But I have a question... How do you get your hair so perfect every single time? I'm growing mine out, and I want to have god like hair like yours.
We just use a very strict naming convention, so it's all about using the find file shortcut. Building a folder structure always fails in huge projects from my experience.
Thank you very much, Kyle! Really one of your best videos! You explain really well how to scale react application. Especially for intermmediate and advanced!
Very helpful, thank you! My only objection would be the name of the "services" folder. Every other folder contains the type of thing corresponding to that folder's name. OTOH, the services folder contains clients to APIs/services, so I'd probably go with "clients" instead of "services".
This inspired me and today I went on a node.js rampage to automate my setup. I made this amazing program with yargs, and learned how to make a global cli command for access to it with the package.json bin. The features folder is awesome. Except wheres your Docker file? 🧐 Looking forward to your hooks video.
Even more advanced structure for large projects is monorepo with separate apps and libs managed for example by nx build system. So for example, authentication feature is separate lib that have just that and use other smaller libs as dependency.
Hi Kyle. I love your videos, and even an ancient architect like myself has learned a thing or two :) I'm curious about what are your thoughts on using extensions to identify the type/intention of a code file, similar to `App.test.js`. e.g. - `text.utils.ts` vs,`textUtils.ts`, - `user.model.ts` vs. `userModel.ts` - `subsection.routes.ts`` vs `subsectionRoutes.ts`
I have started to use those extensions for my files and I see myself only benefiting from it (but note that not every file can have extension). To have an example - I have folder 'types' and there is modal.types.ts This way when I am looking for modal types I can type modal.types and this will be the first file (as I have also other components named modal, eg. ModalRenderer). So it will significantly ease the searching for file and that's what you want in most cases.
great tips. just followed a react vid to make a portfolio site, and was unsure about how i wanted to go about the files when i start to personalize and add to it. ill be using intermediate style as it looks robust enough for a personal project
When using a “framework on a library” like React Admin I think it’s a bit different, as the components do so much heavy lifting that you can have a relatively simple folder structure while having a fairly complex app.
If you have features that can be completely independent like that you may want to consider using module federation instead. Though it is a good idea to build like that from the start so that you can easily mfe it later on.
In my projects I use something between the 2nd and 3rd approaches. I've always formulated it as "the App is a component, it consists of components". Therefore any tiniest button can be thought of as a separate app, however simple it might be - just a different app solving a specific task. Regarding the "features" folder, here it is described as a special case. But you've already had "pages" and "components" by then, so why not use the concept of collection folders? In this case you may have any number of plural-named folders with related components on demand, at any depth in the project (since all depths are equal, all being apps).
thank you maaaaan! for now it looks logical, but before your video it was always a headache to understand th structure & place my code into correct place in difficult project structure
Hey Kyle, please make a video that explains how to use tests in react project? Cause first thing I always do is get rid of every test script in the CRA boilerplate.
folder structure (especially in React) is soooo opinionated. it would serve you best to think "how will it scale" when deciding or changing a folder structure instead of memorizing a/b or c. also, most projects scale over time both in dev# and in features so its reasonable to think that they will also require a change of folder structure
React actually has very unopinionated folder structure. You don't have to follow any of this aside from adhering to whatever your framework of choice enforces (i.e. page directory in Next.js). Imo, this is overanalyzing folder structure. I think following a structure of only separate when necessary is always a better mode than trying to prescribe a folder structure to your codebase.
I would prefer to see that while you are creating a real project it would more helpful and on way or another it was very helpful to get that as a junior
I have learned design patterns for building large scale projects in php framework like Laravel. There is a Famous Pattern Called Do-mine Driven Developement which same like a feature folder that you have explained But really a Great idea to structure like this.. thanks for sharing this with us
that's a great one!! absolutely beneficial, thank you so much, this video and the design pattern series are incredibly useful and helpful, I really appreciate your work! keep it up. 💪
Great video as always Kyle-- thank you! In the intermediate and advanced folder structure, where do you store the css files? I only saw one css file in the assets folder -- do you usually put all your css in one file? I would think there would be multiple files as we would have styling for each component and then styling for each page (to put the components together). I'm new to this so I might be completely off-track here!
It's been 8 months since this comment was posted. But I was just about to ask the same thing. I think the best practice here if you're going for an intermediate/advanced file structure is to include css files in the component folder for each component. Makes the most sense to me anyway. If you're going to the effort of modularising each component in its own folder, why place the styling for those components anywhere else? I guess maybe you could have a css/styles folder, and then put each component css in it's own folder/file... Something like this could look like: components/form/[ styles/[ button.css, checkbox.css, input.css, ... etc ], ... components ] ... other components
i think for enterprise level we need some kind of clean architercture with 4 layers like presentation infrastructure domain and application with dependency injection and repository pattern this will follow the mvvm pattern also
Sure, in the javascript world, tests go in the same folders as the production code they test, but tests being in a completely separate folder has been the norm in the Java world for decades.
Dont think 3 is generally necessary even for large projects. Might be a good addon for some cross cutting concerns mixed with the page folder model from 2
Great video! Can you make a similar video on a Next.js project with a bunch of features, api endpoints and different types of page renderings (SSR,SSG, etc). It's really daunting to make sure you isolate frontend and backend code, as well as features.
Can't believe this isn't more documented on the web yet. People need to start talking more about what it looks like to build projects with enterprise level structure :D Great Stuff!
This was my very first concern learning how to make simple apps back in college. Nobody was really able to answer my question and just like you said, it's not documented at all online! It would have sped up my learning so much.
@@pleasejustletmebeanonymous6510 while that may be true, just seeing one example that's thought out and explained is a major help in getting my head wrapped around the bigger picture of the application. It can then help me better understand other projects, regardless of structure. But now I wonder if many projects will have to be re-written with the help of AI lol
@@pleasejustletmebeanonymous6510 Agreed, but I would like to add that it is the responsibility of leadership and management to work on this, and the devs should be vocal about it.
This is what I do as a front-end specialist:
- domain: This is a suggestive/temporary name that represents the only(and the main) module that the application has. If/when the application scales, new folders like this would be created for each domain, so we could have 'users' (for example) and its components, pages, icons, hooks, etc., and another folder called 'payment' and its components, pages, icons, hooks, etc. It is important to highlight that an application domain can have multiple pages and that those pages will be sub-routes, for example, users/registration, users/permissions, etc
- shared: A folder represents code that is used/reused without being tied to any application's rule. This folder is not called 'common' because it does not just hold common code but also has the potential to become a private/internal library - other projects within the same company could be using a versioned flavor of this folder. Regarding the project's structure/organization, this folder is also a container for another folder, so it will hold shared components, models, icons, hooks, etc.
So...
Pages (and page folders) will not be treated as containers for multiple pieces of code, as this only happens with domain and shared folders. Pages will be treated as normal components, with the difference that they will be rendered when we reach certain routes. That said, components and pages will use the same naming conventions, coding patterns, testing approach, etc
As far as my experience allows me to say, I can add the following:
1. the 'junior approach' becomes very problematic as soon as a second programmer start to work on that code. So I would directly jumpt to the second approach
2. The third approach is very near to the hexagonal architecture, which facilitates the ownership of each programmer in a domain, reduce the risk of conflict and makes it cheaper to transfer the domain to another service. At this point, typescript should be used, and a "dto" folder for types should also be added.
you mean interface? dto is for api
One big addtion to consider is a template/transform file structure for API calls. When dealing with mock data and mocking all API functions, having a specific data/API/Mock folder system is super helpful Our rule of thumb is a file per URI so /v1/files GET/POST/PUT would all get its own template transform file (turn BE values to FE values and the reverse), a mock API responce File, and the accociated tests for them. That kind of breakdown makes dealing with the API layer much more tidey.
if you have any reference code regarding this can you provide the link please
So you have any reference code regarding this? :D
great video! would love to see a next part on a nodejs / express backend api!
yes! please! ive been having trouble with this
W
ratio plus html / php
There's no need, just use Nestjs instead
same here
Neat idea! Would love to see a followup on monorepo structure.
Yeah mono repo +1. Shows us the structure for a multi tenant app.
As junior Dev, it's great to see these patterns half of which I formulated on my own, the other half I'm learning here 😅
😂 hmm
I did this project without watching it first. I used "startsWith" method instead of "includes" . It sorts words much logically 🙂
Thank you for teaching useful projects
The Combination of Pages Folder and Components Folder in medium size projects really make structure cleaner.
as always, so clear and well explained.
I suggest you to share an actual project (if you can of course) for each type of structure. It would be amazing, I guess a lot of people likes to have an exemple to work with as I do.
anyway, just keep going you are amazing !
ha and thanks for the free course :)
he has shared it's in the description
Hi, Kyle! I heard you said once that, before getting your first job, you had researched the companies for which you were going to apply before actually applying to their job offers, so that you could focus your efforts, instead of sending tons of applications, and also make sure you'd end up in a work environment you'd like, and all that payed off in the end. Could you please share how you got informed about the companies' cultures and how did you know they would be a good fit?
This was extremely helpful! I'm building a rather large project and couldn't think of a clever way to structure my files. As I'm still at the start it'll be quite easy to apply your method of folder structuring.
One thing i usually do is create a folder for each component. the folder contains an index.ts and a "ComponentName.ts" (or .js if you use that), the component is exported as default from the index.ts, this way, you have a folder which encapsulated everything related to that specific component (styles, tests, logics, etc..) AND when importing you only have to reference the folder instead of the folder and the component because it's exported from the index.ts, (eg import ComponentFoo from "components/ComponentsFoo" instead of "components/ComponentsBar/ComponentsBar") best of both worlds. I already hear the question "Why only export from index.ts and not just place the entire component there?" ---> because if you keep it separated you can still easily search for components in a growing code-base.
Thanks for this. I already had a pages , components and a sub-components inside components. I just added a data folder and moved my data into there. I created a utils folder but I don't have anything in there yet.
I wish you had a course making a full complicated website (with auth) from beginning to end. I think the hardest part is putting it all together
Video suggestion: best practices for publishing react components as libraries
Yep, folder structure it's important for each project!
With your approaches, I can scale my app easily.
Great video.
Instead of having those global folders, you could create a "global" or "shared" folder under "features" and get rid of that duplicate folder structure. This way you have src > features > [authentication, projects, settings, shared, todos] > [assets, components, context, data, hooks, ...]
this/similiar structure combined with Material Icon Theme (VS Code has it as an extension) can do wonders
Really bro 3rd method is really advance level..
Appreciate your teaching skills👍👍
Yes, been using folder-by-feature with my team for the past 3-4 years. Scales really well, because ourcode base has around 8-9 people actively commiting to it. (It's a monorepo too)
Thanks so much for making this video! I've been searching for a breakdown like this for some time now, and this will help a lot with structuring my NPM projects' folders.
As a pro react engineer, this is the first time I've seen it explained like this... it makes so much sense!! Thank you!!!
Why put entire libs under libs folder if it is much more simple to update package.json ?
@@nathanr6479 the package.json is your blueprint, your package-lock.json is your actual installed modules and libs would contain the code you write for them, you don't always just import a module into your components.
@@Jrrs2007 that is great
Great video! I've been looking for feature pattern of react for weeks, and this is the most perspicuous one.
This is great. Using standard and best practise project folder structure is very important.
Clear and neat folder structure . Just few additions may be a folder of constants, router and store for state management
It always weirds me out the tiny amount of talk on this topic, for me one of the most difficult things in a react project (or any project, really) is the folder structure. A great work as always Kyle
Tiny amount? Perhaps it is a matter of perspective, but for me it seems like this is what everyone talks about!
also readability and DRY code
It’s like you just read my mind. Waiting for node/express pro folder structure.
I have looked for 6 days how to organize project structure properly for full-stack app I have learned smth but there are too many examples so I got confused. Thank You! 🚀
Thanks, finally someone talk about react project file structure.
My team and I essentially use this same structure for our Big Pharma clients like Pfizer and Novartis. A little 2 cents about what we do - we first take the src folder and put a front-end & back-end folder in there. With the new server components coming out, we thing its a good idea to begin adopting this now. Then in each of those folders we have a "common" folder - which is obviously components that have the potential to be used everywhere, but being explicit makes life easier yall!! lol then we have a breakdown very similar to what is in this video except the frontend folder handles all the static assets, and no "services" since we have a server, api, middleware, auth, etc. folders in the main backend folder and the FE folder again has almost exact structures shown here - hope someone gets something cool from my ramble lol
The only problem I have with React is the freedom they give u to decide your project structure. I love React a lot but I normally choose Angular just because it structures your project for you.
idk why this is never part of tutorials. I just wish tutorials would show how to break down files and folders with react etc. thank you
hallelujah some clarity on building real world react apps...not the usual tutorial toy project
Great video! Would’ve been nice to see how a small application file structure is turned into a medium sized application’s structure and so on…
This is nice. It would be great to see the files as you went along.
please keep doing what you do you are my favorite youtube coder when i need to understand a subject , you helped me alot
I searched for this video a few weeks ago, thanks for making this!
(More advanced) I would move root level features, services, hooks and other stuff thats esssential for the app to function to a new folder called 'core' for easier folder structure. I would also add 'store' folders to features. I would also add the folder 'domain'. I would use this with domain driven development. I would put pages components, hooks, and services there too. I would put all http-based services in an seperate folder called 'http' too. This is for being as clear of whats going on.
I was looking for this the past week!! Super great timing!!
I use like this: core(auth, interceptors, etc), shared(reusable components), features(pages and related features to that page), layout(header, footer, etc), helpers(helpers functions, constants)
are you still using that now?
Encapsulating everything in your index.js file is an anti pattern and will have issues with tree shaking code you may not be using, or when dynamically importing. Instead, you can use a ts/js config to set paths to make imports without awkward ../../. Also, I’d avoid any default exports when writing application code as it can lead to team members naming things confusingly.
Depends on the module pattern. If you use ESM and export (not export default) and import (not import * as) this is not a problem. Most tree shaking nowadays does static analysis to both find out what you import and their dependencies and only include that in a build.
However, consolidating exports in an index file has the disadvantage that it can create circular dependencies (if you import it from re-exported files), makes dynamic imports import unnecessary files and make builds slower due to this optimization path.
It's fine to provide a library which exports public APIs (i.e. a ui library that exports components that should be consumed by apps), but internally it can create a headache.
How do you remove the awkward ../../?
In nextjs i use the baseUrl:"."
But in react does not work, how do you do?
@@spiderdev5166 you mean like an alias in webpack?
@@kevinbatdorf Im talking about the imports
instead of: import {Component} from "../components";
like this:
import {Component} from "components";
I appreciate your videos. I love watching them. I've been banging my head with good folder structure, so thank you for this.
But I have a question...
How do you get your hair so perfect every single time? I'm growing mine out, and I want to have god like hair like yours.
This came just right in time. Thanks so much
Thank you for this helpful video bro. I really appreciate you for sharing infos that no one shared with us in our companies.
Great explanation, hadn't thought of the features approach in that way.
We just use a very strict naming convention, so it's all about using the find file shortcut.
Building a folder structure always fails in huge projects from my experience.
Agreed. Too much structure actually makes it harder to find things. Strict naming and a relatively simple folder structure is best IMO
This is the main reason I went the angular route.. It forced me to structure and organize right off the bat.
Thank you very much, Kyle! Really one of your best videos! You explain really well how to scale react application. Especially for intermmediate and advanced!
I am using the last structure for all my projects now. On an unrelated topic, please do a video on creating a WYSYWIG Editor with draftjs.
Very helpful, thank you! My only objection would be the name of the "services" folder. Every other folder contains the type of thing corresponding to that folder's name. OTOH, the services folder contains clients to APIs/services, so I'd probably go with "clients" instead of "services".
This inspired me and today I went on a node.js rampage to automate my setup. I made this amazing program with yargs, and learned how to make a global cli command for access to it with the package.json bin.
The features folder is awesome. Except wheres your Docker file? 🧐
Looking forward to your hooks video.
This is Gold ❤ Thanks brother for sharing such with the world. This will definitely be helping freshers a lot.
Its amazing how u know so much detailed stuff and yet explain it all together in minutes 🎓
Even more advanced structure for large projects is monorepo with separate apps and libs managed for example by nx build system. So for example, authentication feature is separate lib that have just that and use other smaller libs as dependency.
simplified as usual! I will apply some of the logic to my NextJS projects
Hi Kyle. I love your videos, and even an ancient architect like myself has learned a thing or two :)
I'm curious about what are your thoughts on using extensions to identify the type/intention of a code file, similar to `App.test.js`.
e.g.
- `text.utils.ts` vs,`textUtils.ts`,
- `user.model.ts` vs. `userModel.ts`
- `subsection.routes.ts`` vs `subsectionRoutes.ts`
I have started to use those extensions for my files and I see myself only benefiting from it (but note that not every file can have extension).
To have an example - I have folder 'types' and there is modal.types.ts
This way when I am looking for modal types I can type modal.types and this will be the first file (as I have also other components named modal, eg. ModalRenderer). So it will significantly ease the searching for file and that's what you want in most cases.
great tips. just followed a react vid to make a portfolio site, and was unsure about how i wanted to go about the files when i start to personalize and add to it. ill be using intermediate style as it looks robust enough for a personal project
Great simplified explanation, thank you.
you can also make your features with package.json workspaces
that way you dont accidentally import from features directly
When using a “framework on a library” like React Admin I think it’s a bit different, as the components do so much heavy lifting that you can have a relatively simple folder structure while having a fairly complex app.
If you have features that can be completely independent like that you may want to consider using module federation instead. Though it is a good idea to build like that from the start so that you can easily mfe it later on.
In my projects I use something between the 2nd and 3rd approaches. I've always formulated it as "the App is a component, it consists of components". Therefore any tiniest button can be thought of as a separate app, however simple it might be - just a different app solving a specific task. Regarding the "features" folder, here it is described as a special case. But you've already had "pages" and "components" by then, so why not use the concept of collection folders? In this case you may have any number of plural-named folders with related components on demand, at any depth in the project (since all depths are equal, all being apps).
Reusability should be first argument.
@@sidbee604 reusability could be use the decoration pattern in a component
Hmmmm, yes, this is why my project is falling apart. I need to put my files in the right places....
It’s the hate army bruv
my life has just been changed by your video!! #ReactFolderStructure !!!!! Yes, please!!!
Please do a video on
HOW YOU STYLE YOUR HAIR !!!
Coz man.... it's so freaking cool 🔥🔥❤️
Thank you so much for this great video about components tree / folders structure in react apps!
Ur the teacher I never had
thank you maaaaan!
for now it looks logical, but before your video it was always a headache to understand th structure & place my code into correct place in difficult project structure
Thank you. Hope you make this video sooner.
Hey Kyle, please make a video that explains how to use tests in react project?
Cause first thing I always do is get rid of every test script in the CRA boilerplate.
folder structure (especially in React) is soooo opinionated. it would serve you best to think "how will it scale" when deciding or changing a folder structure instead of memorizing a/b or c. also, most projects scale over time both in dev# and in features so its reasonable to think that they will also require a change of folder structure
React actually has very unopinionated folder structure. You don't have to follow any of this aside from adhering to whatever your framework of choice enforces (i.e. page directory in Next.js).
Imo, this is overanalyzing folder structure. I think following a structure of only separate when necessary is always a better mode than trying to prescribe a folder structure to your codebase.
Please do a course project using this advanced folder structure.
may our folder structures remain as neat and clean as his hair.
You: "Hey dude, I was wondering if you could help me structure my Rea..."
Lead dev: "MORE FOLDERS!!!"
Can you also discuss the Atomic Design Pattern because that is what I've structured my component folders in my projects/company projects
„features” folder is also often named as „modules”.
or “packages” in mono repos
advanced version feature is like angular module
the best folder structure is one you can past on to another developer with little to no documentation.
I would prefer to see that while you are creating a real project it would more helpful and on way or another it was very helpful to get that as a junior
thank u for the folder structure
You know, you just read my thoughts 🙏🏼😊
I have learned design patterns for building large scale projects in php framework like Laravel. There is a Famous Pattern Called Do-mine Driven Developement which same like a feature folder that you have explained But really a Great idea to structure like this.. thanks for sharing this with us
that's a great one!! absolutely beneficial, thank you so much, this video and the design pattern series are incredibly useful and helpful, I really appreciate your work! keep it up. 💪
Great Video, please make some Project usecase video with "Advanced" structure using react
I'd love your opinion on microfrontends, turborepo, and monorepos in general for microfrontends architecture
It looks good! But we still need time to work on it to see how good it is
awesome video with great advices! Can you do another video to guide us how to re-use React components across Projects ? I used to copy-paste...
Whould be great also to see how to structure right next.js + ts. Thanks for vid
feature sliced design is the best approach
Great video as always Kyle-- thank you!
In the intermediate and advanced folder structure, where do you store the css files? I only saw one css file in the assets folder -- do you usually put all your css in one file? I would think there would be multiple files as we would have styling for each component and then styling for each page (to put the components together). I'm new to this so I might be completely off-track here!
That was my exact question. I guess I could put it in it's own folder for now. But would love some insight from someone who knows what they are doing.
It's been 8 months since this comment was posted. But I was just about to ask the same thing. I think the best practice here if you're going for an intermediate/advanced file structure is to include css files in the component folder for each component. Makes the most sense to me anyway. If you're going to the effort of modularising each component in its own folder, why place the styling for those components anywhere else? I guess maybe you could have a css/styles folder, and then put each component css in it's own folder/file...
Something like this could look like:
components/form/[
styles/[
button.css,
checkbox.css,
input.css,
... etc
],
... components
]
... other components
Just to follow on from that:
I suppose you will want global styling too, in which case it does make sense to have a styles folder at the top of src/
i think for enterprise level we need some kind of clean architercture with 4 layers like presentation infrastructure domain and application with dependency injection and repository pattern this will follow the mvvm pattern also
Well done Kyle!
Really appreciate this man. Thank you!
Sure, in the javascript world, tests go in the same folders as the production code they test, but tests being in a completely separate folder has been the norm in the Java world for decades.
Kyle you rock. Thank you. Awesome video, learned a lot
Dont think 3 is generally necessary even for large projects. Might be a good addon for some cross cutting concerns mixed with the page folder model from 2
Can you show us how the advanced react project will like , for example as you said no imports inside features so how's it gonna work?
Bold of you to assume my features don't have their own features.
JK, thanks for another great video!
Great video! Can you make a similar video on a Next.js project with a bunch of features, api endpoints and different types of page renderings (SSR,SSG, etc). It's really daunting to make sure you isolate frontend and backend code, as well as features.