The most important thing isn't having the best structure in the world.
The most important thing is having a pattern.
[♫]
Hey dev! There's a lot of people that ask me what is the folder structure I use in React projects,
being them React for web or projects in React Native, alright?
And now I'll show a little bit more or less how I set my project up,
how I separate the files inside the project and where I place each file inside there.
I'll also show a little bit of what is the behavior of my component,
how I separate
the... logic of my component, the viewing part,
styling, so I'll show a little bit of how this all looks on my code, alright?
I'll show you this here in a React Native project, but it could be on a React for web project,
using the "create-react-app", or anything like that.
And now, a few things before I start this project.
Everything that I'll explain here, works just as fine for React for web and for React Native, of course it has
specific features between these two platforms.
For example,
uhm... today, for now on React Native, before version 5 of React Navigation comes out,
we have all the routes written in a for-- everything with JavaScript.
There on the web we have all the routes written in component format,
when we use the "react-router-dom".
So, there on the "react-router-dom", when we need to create a few routes, for example,
private routes, that will only be accessed when the...
the user has... an authentication, and all that,
so it starts generating more files, so we have to do a specific setting,
for the web part.
But everything that I'll show you here in this video are settings that
all the projects I have the same thing.
But, also, of course,
you're allowed to include your own settings, your own structures.
But a lot of people ask me "Diego, is there a specific structure
that will adapt to all React or React Native projects or any other programming project,
and... and will scale to infinity and beyond?" No, there isn't. There isn't a structure, let's say it like that
100% scalability proof.
So, what I recommend is,
create a structure, based on mine, based on another structure that you like, uhm...
define this structure with your team and try to always use the same structure,
To always have a pattern.
The most important thing is not having the best structure in the world.
The most important thing is having a pattern.
So, you have the same pattern in every project,
not running away from the pattern inside the same pattern is really important, alright?
So now, that my project is already created, I'll access it here.
I mean, I wasn't recording my screen, now you can see my screen.
so let me start recording here.
Alright, I had only created a React Native project,
So here it is, I created it, uhm... with "react-native init",
so, here inside the "temp" folder, "structure", here is my project, I'll open it on VSCode,
perfect, now, here inside the VSCode I have my folders,
I mean, I haven't opened-- oh yeah, I did, it's here on the side.
VSCode was open before.
Alright, now, how do I do the organization of a project like this, that I start with React Native?
I create an "src" folder,
I leave all my application's code inside this folder, I don't like to share,
uhm... any other ode, any other code that will be held by my team
inside other folders here of the project, so this app that is here goes out,
I take this "App.js" off,
and I create an "index.js" inside the src folder.
Here inside, I create a... functional component from React Native,
I can use the Rocketseat's snippets here,
I'll call it "App" actually,
Alright? I save this here, ad now, on the "index.js" here from the root,
I import my App from inside my src folder,
and not from the "App.js" file.
Alright. From now on, a lot of folders that I use starts to unleash.
The first one of them, "pages", is where the pages of my application are kept.
Since each page of my application is a component, I always put each--
each page, with each component inside here.
And I don't simply put if I'm gonna have a page, let's say it like that, for login.
I don't put "login.js".
I don't like to use it this way, because this way we'll have
our style and our component inside the same file, right,
I would have to create all the styling here.
Or, at most, I have seen people creating for example, like this, look, "login.styles.js".
You can do it like that, but I don't really like it. What do I usually do?
I delete this here, I create a folder named "Login",
alright? And inside it I create the "index.js",
which will be my component,
so here the Rocketseat snippet already identifies that I have a "Login" folder,
and it already puts the name of the component correctly.
Now, inside here, I create a "styles.js",
and here I use Styled Components a lot,
if you don't know what Styled Components is, there is a video on our channel explaining this.
and here I simply add a "styled-rn"
and it creates the structure basically for me here
of a component styled by Styled Components. And then I take this comment off,
and I leave the container inside here.
This is something that I usually do, alright?
Always, most of the components, it has a View that goes outside from it,
being this View...
it doesn't need to be a View directly but there's a component that goes outside, right,
React needs it.
So, usually I call this "container", no matter what component it is.
And then I have one container per component,
which is the componen-- the element that goes around all my structure from jsx.
Alright? Now, inside here, I don't-- there's a lot of people, and this--
uhm... After the hooks came,
it didn't make sense even more, I didn't even think it made sense before,
but there were a lot of people that
separated the component
in-- in two components, let's say it like that... in two-- in two-- in two files, right?
Uhm... its the pre-- I guess people called it "presentational" and "container",
which is the part where the visual part used to be, the structure, for example the texts, the inputs, the forms,
and the part
of the container of... the functional part where the JavaScript code used to be,
the functions, the connection with Redux, uhm.... and all that.
I didn't like it like that back then,
I never used it in this format, I tried a couple of times and I didn't find it productive,
and... I didn't find it more scalable, let's say it like that,
and now with the appearance of the hooks, and if I'm not wrong,
I might be saying something nonsense so I won't mention the name, but there's a guy from...
well... uhm... influential on the React community, he said that
this part of separating in presentational contai-- uhm... and containers, totally died, because,
dude, with the hooks we can leave everything really organized in a single file,
so I only separate the file that will be jsx
of the styling file, I don't do any other separation. Alright?
Now, that I already have my pages here, I can create other and other pages,
and I always create a folder named "components" also, here on the root of my project.
In this "components" folder, there are components that I will share throughout
all my application.
So think, idk, forms, buttons, uhm...
idk, or any type of component that I will use a lot of times inside my application.
So, if a component is used in at least more than one page,
it goes inside the "components", alright?
"Oh, Diego, but what if I want to create a component that will be used
exclusively in one page? But I want to separate this in one component,
being cause of the performance, being so the code can be more legible,
alright. Then it is a different situation, I don't put it in this folder here.
If the component, for example, let's suppose that the "Login" page
was here with a component, idk, named...
uhm... "ForgotModal", that it has a... a... a modal
of "Forgot my password", that will be used only inside the login,
so, I create this here, "ForgotModal",
alright? And here I have an "index.js" one more time, and the "styles.js".
And a lot of people tell me "But Diego, aren't these 'index.js' a...
a crazy idea? Because, this way, I'll have
several "index.js" on my application it will be really hard to find the file I want"
of course, it will be...
it will be difficult to find the file you want if you type "index.js" on the search bar,
but if you type for example "ForgotModal", it is already there,
the "index" and the "styles", so it is really fast to access
these components, I don't se any problems,
on the productivity topic, of finding yourself in the code,
and I really think that today this is the best structure possible.
And...
I've wasted a lot of time trying to figure out structures
and... us as programmers we really want to "ohh, I'll start my project with the best structure possible,
because the project will be scalable"
but like I said before, all this that I'm showing you is something I figured out throughout time,
and is something I do in all my projects.
But, every project it ends up running away a little bit sometimes of this main structure,
because each project has its own singularities.
It might be a project that has a really strong part, for example, of...
offline, right, of... of...
offline functioning, offline first,
so it will need to have a lot of different settings,
that will result in a structure a little bit different,
there may be another app that is a game for example,
so the structure will be totally different,
so this right here is the base that I use for all my applications, being Native or Web,
but we have to understand that there WILL be
singularities in each project, particularities,
and the most important thing of course is to keep a pattern inside the team,
so that another programmer takes your project and is able to at least understand
your structure, right? And not having a different structure for each project.
Alright, now, besides my "components" folder, that include more global components, for example, idk,
a button, the button will have several sizes, several colors,
it will be able to have a border, will be able to have an icon, so
usually I have a button component on my application,
I create all this from square one so I can have the icons and more, the buttons are usually all the same
inside my application.
And now, I always have an "assets" folder.
On this "assets" folder, I include all the structural files, static structural files.
What do I mean by "structural files"?
That they are
uhm... part of the structure of my application, of the visual structure of my application,
so, for example, if I have a logo on the login page, it will be here.
"Oh Diego, but this logo is only used on the login page,
shouldn't I put it inside this login folder?" No.
Leave them all at "assets".
Everything that are pictures, and not only pictures, right,
uhm... for example, what can also go inside here--
can also come inside here,
uhm... idk if you know it, but React Native has an integration with Lottie,
right? Lottie is a library,
that we can convert animations done in AfterEffects, a good video, right...
if you'd like to see Lottie in action, leave it in the comments.
But, Lottie is basically a library that
converts animations done in AfterEffects, it exports to a...
to a JSON, it can read it inside React Native
and show those animations on the screen,
so since this here is a part that do--
is something that is part of the structure of my application, is more of a visual thing, it is an asset,
I put it here to. So, it's not only the pictures.
"Diego, here inside the assets, can I separate them?
For example, I want to separate them in folders,
uhm... assets that are related to animations" dude, here, it's whatever,
here you separate them by the best way possible,
but we have to understand that on the assets, there are static structural files of the application.
And then, what I have here usually also is a "config" folder,
that I do the settings of a few plugins, of a few extensions,
and here usually goes the Reactotron config, the config of...
uhm... the status bar, sometimes, even though nowadays I'm using the status bar config more often
on that component in written format,
so... dude, any plugin setting,
of-- of what you'll add, specially for the development environment, I add it here.
For example, "uhh I'll install"
uhm... "Reactotron", or even "React Dev Tools", I'll install anything else,
I put the settings here inside. Alright?
And then I also have one more folder here that is also really important, that is called "services".
"services" is also any type of setting,
but it is a setting related to services, right, what I mean by services is,
they are settings with...
libraries that will do some sort of communication
with another end point.
So, communication with another end point, not necessarily a communication with an API,
so for example, here on the services I put-- I usually have an API,
that I do here the Axios setting, but for example, if my application uses a RealmDB,
or a WatermelonDB,
or an Apollo to communicate with GraphQL,
or uses an SQLite base, a little bit more detailed,
everything that we'll use is some sort of communication service of our application
with another...
uhm, another end point, I put it inside "services", so we can think of services
as communication API Settings, alright?
so, let's go,
uhm... I have one more folder here, let me check my cheat sheet here,
I have the little folder named "store",
on the "store" folder I do all the settings
of Redux, and not only of Redux, if you're using MobX, if you're using any other type
of... library to the Flux library, to
store management, I do it here.
If I weren't using Redux, If I were also using, for example, idk, only Context API,
you could also do it in here. So the store will be where the data from our application will be stored.
So, we...
if you have never heard about Redux, maybe this here is a little bit confusing for you,
but when we use Flux architecture libraries we have
uhm... a concept that is called "Single state of truth",
which is basically a single state of truth [he's explaining the meaning of Portuguese]
so we keep the state of our application, not all the state,
inside of a point where all the application can access,
so a manageable state by our-- of our application,
that can be accessed by multiple components and also manipulated by multiple components,
once that in React,
if... if we use for example the state inside a component, it's really bad to keep
sharing this state with the other components.
and then, here, we can play a little bit more, for example, I can also have a file of
"routes.js", that I have basically on the entire project,
uhm... and this "routes.js" is for the definition of my routes,
and inside here, uhm... I can have more things, let me chek if I have something...
something else in any other project, oh, another thing that I can also have,
that sometimes I do, sometimes I don't,
is having a "styles" folder inside here,
that I define common styles, and here they aren't common components, they are common styles.
So for example, if your application have themes, right?
So here I create "themes"
and then I create, idk... the "light" theme,
the "dark" theme,
and then I export from here
the settings, for example, on the "dark" theme, the primary color
is gray, a really dark gray, and the secondary color, and so on, and I do it on the "light" theme too,
and then we can use the Styled Components, to show these information of the themes,
to all my application, so, as I said, this structure is totally changeable,
but here I did a recap, let's say, 100%
of the structure that I'm using in projects even for ReactJS, right, for web,
and for React Native. If liked this structure,
if you will use them on your projects, leave a comment below
if you want to give any suggestions so I can improve even more this structure,
I'm totally open-minded, like I said, this is a structure that
took me a long time to define as being a... main structure,
but me, also, when I... when I started learning React, React Native,
I also kept trying to find a perfect structure, a scalable structure
that could be used in all projects,
and actually I already understood that it doesn't exist,
and now too,
I'm telling you this, it's a really precious tip, don't try to look for the best structure of the world,
you can create your own structure based on other structures and define this with your team,
and keep a pattern, file this really well, so that everyone can have the same pattern.
I'll be here for now, thanks!