Hello friends welcome to coding garden and welcome to this preview of my course react Roots which teaches the basics of building single page web applications with react and typescript if you visit reactroots.com you can learn more and if you click on the section what will I learn in this course you can see all the lessons from the course and specifically today's preview is from Lesson Four and the learning objective that we're going to be covering today is use a consistent and predictable folder structure to organize code so hope you enjoyed this preview if you do definitely check out reactroots.com to learn more about the course here it is one of the things that I wanted to talk about was directory structure because a lot of you had questions yesterday about well should it be in separate files should we put it in separate folders and just like everything else it's totally up to you you get to decide that react in typescript you don't have in JavaScript don't have any opinions about that you can kind of do whatever you want but I'm going to spend five minutes showing you some some common patterns so you can have make better decisions about how to organize the code in your project so yesterday you saw an example where in the source directory I actually created a folder called components this is standard you see this in in most react apps and you can start to put your components that are used in multiple places in this folder and the reason I say that is sometimes you have things that are not reusable right some sometimes there are components that are literally only used in like one section of your app so it doesn't make as much sense to put it at this top level here you really want to put high level things like a button Etc and actually let's just do that as an example so I might have a button and actually let's do the the name spacing thing that I talked about earlier so let's actually prefix everything with app so I'm gonna have my app button .tsx I have a function at button that gets exported and uh this will just return a button we will take in a label and then we're going to render that label right here and then we'll also take in an on click function and we're going to specify that right here now we need some we need an interface to describe uh this so we'll say we'll call it app button props label is a string and on click is a function that takes in an event we're going to talk about the types today so I'm just going to use the any type and returns nothing to do fix any type and then I can say that these props are of type app button props okay so I have this button and this is absolutely absolutely reusable right because there's gonna be multiple places in my app where I need a button but now I've encapsulated it so that I can do things like I can put custom class names on it custom Behavior I could even start to customize it further and say well this accepts an icon as well maybe it accepts an icon on Union of like thumbs up or part something like this and so now this takes in the icon and then can decide to display the icon on there and then maybe I call this app icon button I don't know all of that to say because this would be used in multiple places across my app that's why I would put it into the components folder all right you might also see something like utils this typically only has like typescript codes you're not actually going to have any components in here say this folder contains helper or Library functions that are used throughout the app I'll also say this could also be named helpers a lot of times people will call it lib lib which is sort a short for Library so Library helpers utils all of those are a similar idea and those also will go at the top level but you might have something like label formatter and then this just exports a function that takes in a label which is a string and then I don't know it splits it on Spaces take in each word capitalize the first letter grab the rest of the word um and then join it back all together on Spaces I don't know basically this this is some function you might use in multiple places in your app where you want to capitalize word multiple words I guess we would do two lowercase on on this one just as an example of something that might be used throughout your application so label formatter for instance might actually go in in like utils the other thing you could have and maybe this would also go like in uh like lib this is all of your reusable Library code and so an example of that might actually be like an API function so a file that has a bunch of API requests inside of it that might go in lib because you're going to use that potentially in multiple places in your app so this might be like API dot TS and then it exports a few functions so we have something like get all and then that would return I don't know what some something maybe I'm trying to come up with example code but also not take too long to to write so that I can show all of this stuff and then let's say we just return response.json I don't know something like this but then maybe you also have like get one and this passes in the ID as a string and then we export these so this goes in library because you might use it in more than one place you might also have like math utils or whatever domain specific thing you're doing that might also be in library yeah so API Keys typically that might actually just go Um you might create something like a config in your utils so like you might have config here and this brings in a library for like schema validation but this might export something like this where you have like API key and then you bring that in from your your dot EnV but then maybe also you have like version number and you use that somewhere in your app there might be other other configurations that you might need in in your front end app we're going to talk about API requests tomorrow so I I'll definitely dive into like how do you deal with DOT EnV and honestly all of all of the apps that we're building in this course are completely front end so you cannot hide your API Keys unless you hide them in a back end in a back-end proxy server back in serverless function basically you can't hide this stuff so instead of super secret this is like kind of secret there are some API keys that you can include in client-side code so that might go in here and then over here in API we might import the config and then maybe we use that API key in our uh headers here and so we say like authorization I don't know config.ap I don't know I really don't know oh sorry I I grabbed from the wrong thing I want to go grab uh utils Slash config like that yeah we'll talk about in variables uh tomorrow but basically you could have a DOT EnV but just know that that EnV is going to get bundled with your application so you could technically do like process.env.react app API key something like this this potentially would bring it in from the dot EnV but again when you build this app it's going to be embedded so that's something important to note yeah so sensitive configuration basically has to be hidden in a back end if you really if really want that yeah so components lib utils uh the other thing you might see so we're next week we're going to talk about routing and you might also see a folder called Pages now this is also a convention like in next.js but if we're just using client-side routing with like react router you could do a similar thing so in here this will be all of the top level pages of the app and so for instance you might have like a home component it is still just a component but then this could bring in further components and like more like nested components I mean maybe we bring in that app button component yeah I saw on the twitch chat someone was like why'd you call it app button a little bit ago I talked about how if you have a lot of components in your app you might run into naming conflicts so especially when we're dealing with typescript so basically like your type could be called button and your component is like app button so I just talked about how you could prefix things to prevent naming conflicts and the other thing you could do is like you could come up with an abbreviation so this is the coding Garden so I could do like CG button or coding Garden button or whatever your company name is like I don't know twitch so if internally you know what I bet there's a TW button somewhere at twitch there has to be right somewhere in their code base but yeah you can prefix it with whatever you want the reason I came to this file is I actually don't want to specify on click all the time I'm going to make it optional so if I make that optional uh home will stop complaining about uh not having it on click for the most part and for for the apps that we're going to be building in this course this is probably good enough this is probably good enough but one thing you could do is now as you start to have in like next week once we start having multiple Pages you can actually start nesting these things so that they're more specific I guess the other thing is we would have we talked about this earlier but we might have a types folder and this will have things that will be used across the app so like maybe there's going to be a user interface like this and so because the this is used in multiple places we put it in the types folder so that way we can keep things consistent so any types used in multiple places go here okay here's the other thing to think about as your app starts to grow let's say you have 20 30 pages in your app and if you just stay with this one level of folders things are going to get really messy right because you're going to have hundreds of components in here you're going to have hundreds of pages in here hundreds of types so what you can start to do is start to Nest these so in here you can for instance instead of just having a home component we could have an entire folder that has all of the stuff inside of it so let's actually do this let's actually let's create another page called like the about page but this is going to be a folder and inside of there we'll create an index.tsx because this is going to hold the about page but also inside of there we could have a nested components folder because maybe there's a one there's a component on the about page that is only used on the about page and so we'll call this like about section component and the about section I don't know just just a div for now but but all the the main point to see here is the fact that this all of this component it is specific to the about page it's not used throughout the application it's only going to be used right here and so now we could bring that into the about component like this and then render it out render multiple of them if we had props or something like that yeah and then we could prefix it as well we could say like the app about page I think like if it's a page maybe we don't prefix it um and then this we actually could call like app about section but again I think it I think it it comes down to how you want to do things but yeah in terms of pages I probably wouldn't prefix those just because they're unique enough but components themselves I actually would prefix and then any any level anything else that is like only used in the about page I might actually Nest here as well so like if there are specific helper functions or utils that are only on the about page I might actually put nested folders here so this is this is how I think about structure I think the other thing like you can go even deeper too right because so instead of having top level components inside of components you could actually have a folder called like app nav bar so you have a folder called that you could have the actual component inside of it but now that lets you put common things next to it so this could even have sub components or it could also just have like Styles so we're going to talk about Styles next week technically if even though we import these here these would actually still be Global Styles but you can start to to manage your your components like in a nested folder as well that's pretty much all I want to talk about in terms of like folder structure and where to put stuff any thoughts comments questions I guess I'll also take input from even the twitch chat like is there something you do in your directory structure that uh you think people should know about or that you like to do that I that I didn't mention oh yeah a good point yeah so uh T TV is uh mentioning uh where do we put ours our Styles yeah and so like if you're using SAS you can basically use the same project setup you've ever used with SAS like inside your Source directory here but you might also create a like if you have Global Styles it might also create make sense to create a folder called Styles and then any any Styles actually go in there so like Styles now has index.css and then we would actually have to fix that so first of all we don't have app CSS anymore and then in main we need to make sure that we import from Styles CSS but yeah you can basically group your your Global Styles together again in order to write Styles specific to a component it typically requires like an external Library so we're going to talk about that next week oh yeah and then if So eventually when you get into like using like the context API or like using Redux or some sort of State Management you would probably have another folder that has all of your Global State stored inside of there as well we haven't got into that so I won't create it but yeah that's that's something good to point out yeah so and I think that's that's maybe something I didn't show in terms of imports so like when I called this about page index.tsx the way that I import it um is actually just still about page so let's say I want to bring the the home page and the about page in here here if I try to use about page why I didn't export it so that's why uh the autocomplete couldn't help me it was like you didn't export anything so notice this so where where it's defined is inside of uh pages about index.tsx but in uh so this is part of the module resolution if you have a file named index it uh you don't have to specify it in the import you can see that I'm importing pages about and it knows to bring in that that index file well this folder structure helped page load no not at all so this folder structure and basically everything we're doing is all about developer ergonomics right at the end of the day I can put things in as many files as I want in as many places as I want but when we run this all through Veet and the build process it's going to optimize everything to have the fewest number of files the fewest number of bundles Etc so all of the I can do whatever I want here and I don't really even have to think about oh well how many files are going to get loaded on the client and stuff like that because the build process handles all of that the readme file you created each folder is this how you do you do document project structure for project computers or new new joiners on the team you could absolutely do it this way I've never done this this is my first time doing it because I thought this will be a good example because you can actually open up the code base and then look in a folder and it's like hey this is what this folder is for honestly I should I should make a whole site has anybody done that I feel like it basically react needs some kind of style guide there used to be the angular style guide by by John Papa John John uh I guess technically they he did an angular style guide for the more recent one but I that thing was like my my Bible back in the day like it tells you common practice for like where to put stuff and all of that so honestly this would just be a good annotated code base to tell you where to put stuff I'm not opposed to doing this in a code base with multiple multiple people on the team because yeah this will help especially a new a new person on the team like what's this folder for oh okay that helps out and then they can make a better decision about where to put the things instead of getting called out in a code review uh Fallen learns in the chat is mentioning they still use the John Papa style guide I'll show it really quick because it's actually really good um even even if you look at the angular one style guide this the application lift principle code should we should be able to locate our code easily identify code at a glance we should have a flat structure for as long as we can and try to stay dry um this this doesn't just apply to angularjs this applies to even like react code bases even like back-end code bases and then it talks about specifically like with angularjs like how you might structure things by feature so you have folders describing a feature and then inside of that you have specific things as well there's there's a lot of good nuggets of information even in the angular one style guide hello again thank you for watching this preview again check out reactroots.com to learn more I'll see you in the next one [Music]