This course has been updated! We now recommend you take the Intermediate React, v4 course.
Transcript from the "Code Organization" Lesson
>> Brian Holt: Another just really brief section here. Last time when I gave this course and several time's I've given this course, people say, how do you choose to organize your code when you are making large scale React applications? So one, I'm going to show you the way I choose to do this which is based on my experience writing React.
[00:00:17] But there's no prescribed way. There's no right way to do this. It's like asking someone, how do you set up a Java project? Well, there are 19 million ways. There are some best practices around it, but there's not necessarily one way to do it. So I'm going to show you one way, which is opinionated and you should definitely take it with a grain of salt.
[00:00:40] So I made an example application here called photo gallery and it's been open source. You can see it's actually, how old is it? It's over a year old. It's probably about 18 months old. Well, maybe not quite that. So this is actually a Preact application, but it doesn't make any difference.
[00:00:58] In the previous section, I showed you that there's little difference between Preact and React. So this is laid out exactly how a layout of React application, it's the same thing. It's also written in flow type and I'm about to show you how to do type script. But again, those two are so similar, it doesn't really make a difference.
[00:01:15] The core here that I'm trying to communicate to you is this is how I would layout and organize a project. So feel free to check this out, it's on my GitHub. Same source directory. So here, I have one browser entry. This is what the actual entry to the project is it and it's just imports from app and renders it.
[00:01:39] And then if you look here inside of the components directory, every component got its own directory. So if I click into, for example, the navigation link, it has the navigation link. It has its tests and actually let's look at a different one like PhotoStream. Let's look at this one.
[00:01:58] All the CSS for PhotoStream, all of it's in here. The entire world of PhotoStream lives inside the PhotoStream directory, including its test as well and snapshots and all that kind of stuff.
>> Brian Holt: And then here, this index.js. All it does is import PhotoStream and export it. So that if I look here instead of PhotoStream.jsx, if you remember index.js, if you don't specify a directory, it'll automatically import the index.js from that directory.
[00:02:27] So it makes these paths really nice. And this entire application, all it is like a iPhoto showing a photo gallery kind of thing, right? Hey, photo gallery. It's the name of the application. So here's why I like this. This optimizes for deletability. The moment that I stopped using the popover, I just delete that directory.
[00:02:51] All of its tests, all of its styling, all of the code that was associated with it just goes out the window with it. Or if I have something that has children components, those will be directories inside of PhotoStream, PhotoStream photo or whatever. So to me, this is a good way of organizing a project.
[00:03:10] Because it makes it really easy to componentize in your head what goes where. It makes it very obvious and it makes it very easy to keep your project free of dead code, and free of dead CSS. How many of you have dead CSS in your applications? All of you, myself included.
[00:03:31] When I started LinkedIn, I think they had 2 megabytes of CSS. That is ridiculous, because it's hard to delete CSS. Because we have no idea what's being used and what's not. If you do something like this where if you have PhotoStream.css like it's all in here and I just delete the directory, all the styles go with it.
[00:03:53] So you never have dead CSS or if you're doing something like a motion, then it's just built into the component. And so when you delete the component, it goes with it as well. Dead CSS is a problem for sure and this helps mitigate that problem. Any questions about that?
[00:04:09] That's just like a high-level architecture of how I like to do it. I'll keep things like common styles in here, so you can see I keep colors in here. There's some test helpers that I've put in to here as well and you can keep that kind of common like top level stuff in there, as well.
[00:04:27] I'd probably have them for like module like an API client or utils or helpers, or something like that. Yeah, question?
>> Speaker 2: Is there any kind of tooling you're aware of that kind of scans your code base and realize that you have dead components or is that just sort of you should just be aware?
>> Brian Holt: Yeah, I don't know if there's one available for Webpack or something like that, but it's really easy to statically analyze. This never gets imported anywhere, you can just delete it. But normally, that should be on the developer of like hey, I removed this component. I'm gonna go check to make sure it's not used anywhere else and then I'm gonna delete it.
[00:05:03] Never be afraid of deleting code. People get like all upset about deleting code, cuz they're worried that they're throwing away some history or something like that. That's what you have get for. So you can always go back and commit, and pull out code that you have previously deleted.
[00:05:17] So don't mess up your get history is what I'm saying, but please be aggressive with deleting code. Deleting code is my favorite thing to do. Literally, nothing gets me happy. I'm making my life easier, it's like cleaning house. It's the same sort of feeling.
>> Brian Holt: So, that's all I wanted to say about architecture of a project, I think this is good.
[00:05:46] This is the way I design my personal projects, so it's something I would suggest.