Learn about the logic behind our directory.
- [Instructor] Alright, so we've made some great progress on our site. We've given our application instructions about how to get our APIs relay schema, we've implemented routing, a UI library, and finally set up a deployment process that allows us to get our code out to a production environment. Now the fun part, building the components that will make up the bulk of our application. Before we dive into the code, though, we should take a second to do a bit of planning. We should reflect back on our wireframe and think about what parts of the page should be made into independent components, and, more importantly, what parts of the page should be containers.
We should also think which components will need to have access to remote data, which components will need to manage their own state, and finally, which components will want to have some kind of styling. We can imagine putting most of the parts our app into three categories, containers, components, and presentational components. Now, these aren't hard or fast rules. Not every component will fall cleanly within container or component or presentational, but we have some guidelines to think about where each of them might go, and this will help us organize our application, and especially our file directory.
Our containers will be connected to the store and they'll pass data to their children. In our case, that means they'll be connected to relay, and they'll have access to mutations, and they'll be specifying the queries that we're going to want to propagate down to our other components. Our actual components, well, they'll manage their own state. They probably won't be connected to the store, and they'll pass props down to presentational components. Finally, we have our presentational components. These will not manage state, they'll be stateless. And they will just change their styling based on props that are passed to them by their parents.
As we put together our site in general, our workflow will go like this. First, we'll plan out the components needed for a given container. Then, we'll build out the components. Then we'll create presentational components. And then, finally, we'll hook the containers into our data store and write any mutations those containers might need to take. Here's a sketch that roughly lays out the nested quality that each of our component and presentational components will have within their container. Here you can see the template container, which is going to hold our header, our drawer toggle, our drawer, and then the actual view of the game.
Beneath each of that, we can imagine a tic-tac-toe game, a board, and individual square components. The same thing on the left side. Within this drawer container, we can imagine some login things, a drawer list, and then items within the drawer, as individual components.
- Installing local dependencies
- Generating a starter project
- Deploying to Heroku
- Planning your development process
- Using styled-components
- Styling for mobile
- Setting up models on Graphcool
- Creating Relay mutations
- Adding Relay to your authentication flow
- Protecting routes with authentication