‫So as I just mentioned earlier this time around
‫we have no demo application, because we will pretend
‫that we are now building this project for a real client.
‫And so in this lecture I will show you how we can plan
‫a professional React application step by step.
‫But before we go do that let's introduce our new
‫fictional client, so do you remember this very first project
‫that we built at the very beginning of the course?
‫So it was simply this static page that displayed
‫the pizza menu of the Fast React Pizza Company
‫and so now this same business basically needs a simple way
‫of allowing their customers to order pizzas,
‫so that they can get them delivered to their homes.
‫And so this fictional business is now hiring us
‫to build their applications front end
‫and of course we are going to do that using React.
‫So for some reason they already have the backend API built
‫and so our only job will be to build the front end,
‫so the visible part of this application.
‫Now, building a complete application like this from scratch
‫is of course a bit intimidating and so let's learn
‫how we can break this process into multiple steps.
‫And let's actually start from what we learned earlier
‫in the Thinking in React lecture.
‫So back then we learned that we can build
‫a simple React project by breaking the desired
‫user interface into components,
‫then building a static version without state
‫in the beginning and then after that we think
‫about the state management plus the data flow.
‫So this works quite well for small applications
‫that only has like one page and only very little features,
‫but in a real world application like the one
‫that we're going to build next we actually need
‫a bit of a more complete process and so we need
‫to adapt this a little bit.
‫So let's see how we can do that, so when we build
‫a large and more real world application we need to start
‫by gathering the application requirements and the features
‫that the application needs and then based on those
‫we can divide our application into multiple pages,
‫so a bit like we did earlier with the
‫World Wise application.
‫Next up, we need to divide the application
‫and the application features into multiple
‫feature categories, so basically we need to place
‫all the features into a few categories, so that we can then
‫build the application around those
‫and so that we can organize or code any logical way.
‫And if all this sounds a bit confusing, then don't worry
‫because next up we will of course do all this in practice
‫with the application that we are currently building.
‫But anyway, finally, we will also need to decide
‫on which libraries we actually want to use.
‫So we call this the technology decisions
‫because this is basically where we decide
‫exactly what tech stack we are going to use to implement
‫our application.
‫Now you see that I left some empty spaces here in the slide
‫and that's because we can divide some of these points
‫into some sub points.
‫So here as we divide the application into pages
‫for each of the pages, we can think about the overall
‫entity page level user interface and so then comes the time
‫where we can break the desired user interface
‫into its components.
‫So just like we learned before in the
‫Thinking in React lecture, so this is where the steps
‫that we learned about earlier actually come into play.
‫So they are still very valid and very important
‫but we now basically do them on a page
‫and on a feature level and so here we actually have
‫the next one.
‫So here again, for each of the pages we can now design
‫and build a static version.
‫So if we want, so of course we don't have to do all this
‫but it can be a nice guideline for building
‫our applications.
‫Now, there is still one step missing from earlier.
‫So from that Thinking in React lecture which is to think
‫about state management and data flow and so that we do
‫for each of the feature categories.
‫So for each of these categories that we identified
‫we will now need to think about what data it needs
‫and where we can store that data and so that's basically
‫what state management is all about.
‫Now, all this is of course just a rough overview.
‫So in the real world, things are never this linear
‫but still I think that this is a very good overview
‫of the whole process that we need to go through.
‫So with this, at least you have a couple of guidelines
‫that you can use in your own projects in the future.
‫And with that being said, let's now quickly go
‫through these four steps here one by one and apply them
‫to the application that we are currently building
‫or that we actually want to start building
‫based on this planning and we are going to start
‫with the business requirements.
‫So basically with everything that the business expects
‫from this application.
‫So first off this should just be a very simple application
‫where users can order one or more pizzas from a menu,
‫so that's a high level overview of the application
‫that the business wants us to build.
‫And so whenever you need to work on some project
‫for someone, even if it's just for yourself
‫you need to start by gathering a list like this.
‫So next up this application does actually not require
‫any user accounts and so no login functionality,
‫so users simply input their names before they start using
‫the application.
‫Now the pizza menu can actually change from time to time
‫and so it should be loaded from an API that is already done.
‫So as I mentioned at the beginning,
‫for some reason the business already has their own API
‫and so we can just start using that to load the pizza menu.
‫Now remember that users can order multiple pizzas
‫from the menu and so therefore we need some sort of cart
‫where the users can place multiple pizzas before they order.
‫Now, since this app has no user accounts
‫all that the user needs to provide in order
‫to start an order is their name,
‫their phone number and their address,
‫so that pizzas can be correctly delivered and the user
‫can be reached in case there is some problem.
‫Now, if possible, the GPS location should also be provided
‫to make the delivery easier for the company.
‫Now, one important feature that the business requires
‫from us is that users should be able to mark their orders
‫as a priority order, and the cost of that will just be
‫20% on top of the cart price.
‫Now, in practical terms, these orders are actually made
‫by sending a post request with all the order data,
‫so that's the user data.
‫So the name, the phone number and the address
‫plus all the selected pizzas from the cart
‫and so all this data will be sent to the same API
‫that we already have.
‫Now, remember how we said that this is a
‫very simple application and so therefore all payments
‫are made on delivery.
‫So users will only pay in the moment
‫that they actually receive the pizzas at home
‫and therefore no payment processing is necessary
‫to implement in this application.
‫Now, once the user has placed a new order,
‫each new order will actually get a unique identification
‫that should be displayed somewhere in the user interface,
‫because then the user can later look up the status
‫of their order based on this ID and so this is again
‫necessary because there are no user accounts
‫in this application to keep it really simple.
‫And finally, users should also be able to mark their orders
‫as priority even after the order has already been placed.
‫Now, okay, so this is the list of requirements
‫debt or application will need to satisfy,
‫but of course this is all still a bit confusing,
‫so we don't really know how to build our application
‫just from this, right?
‫However, from these requirements,
‫we can now start to understand what features
‫we actually need to implement and so let's take a look
‫at that in the next slide.
‫So basically what we want to do now is to derive
‫the application's main feature categories from the list
‫of requirements that we just saw.
‫So first of all, remember how the user needs to input
‫their name in order to start using the application
‫and so one feature category is going to
‫be everything related to the user.
‫Another pretty obvious category is the menu,
‫so all the features that are related,
‫for example to loading and displaying the menu
‫will be part of this feature category,
‫because the menu is a pretty important part
‫of this application.
‫And another pretty important part that we have
‫of course also mentioned in the list of requirements
‫is the cart.
‫So this is where the user will be able to take one
‫or more items from the menu and add them to their cart
‫and also of course to update the quantities of each pizza.
‫And finally, one of the big feature categories
‫is going to be the order because many features
‫of the application are going to be related to this topic.
‫For example, placing a new order or looking up
‫an existing order based on the ID and of course,
‫in practice, once we start doing this it will all become
‫a lot easier.
‫But for now, what's important to understand
‫is that all the different features that we
‫are going to implement in the application can be placed
‫into one of these feature categories, so basically this is
‫what the entire application is going to be about.
‫So it will be about users, about a menu, about a cart,
‫and about orders and so this basically gives us
‫a high level overview of what the project is all about.
‫Now, from this list of requirements
‫and also especially from these feature categories,
‫we can already start to understand the pages
‫that we are going to need to implement.
‫So first off, we are probably going to need some homepage,
‫then we need a page for the pizza menu.
‫We will need a page to display the user's cart
‫and we will need a page to place a new order,
‫so here we could use this URL of order/new
‫or of course we could do some other thing as well.
‫So for example it could also be called simply /new order,
‫but this makes sense because in our next page
‫we will then have /order/ the order ID
‫and so this page will be to look up an order.
‫So these pages four and five then follow a similar
‫URL structure where they both start with /order
‫and then in one of them we can place a new order
‫and in the other one we can look up an existing
‫order by passing in the order ID as a param.
‫Now remember how in the list of requirements
‫we stated that the user needs to input their name
‫in order to start using the application
‫and so this is how we connect the user feature
‫with the page.
‫So in this case, the homepage because that's where
‫the user will input their name, then of course
‫the menu category is connected to the pizza menu page
‫and the same for the cart and for the order.
‫And so at this we can really see how the feature
‫categories help us to determine which pages
‫we need in the app.
‫So we need one page for the menu, one for the cart
‫and in this case two pages for the order,
‫one to place a new one and one to look up an existing order.
‫And again, this will all become a lot clearer
‫as we actually start building this project in practice,
‫but here we are just doing this long exercise
‫of trying to plan the project before we actually start
‫which is always a good idea.
‫And now moving on in this process let's talk about
‫state management and tech decisions
‫and let's start with state management by bringing back
‫or four feature categories.
‫Now, many times these feature categories actually map
‫really nice to different state slices or state domains
‫and notice how I'm borrowing the term of state slices
‫from Redux, 'cause I really like this term.
‫So basically we have our entire state and then one slice
‫of that state will be the user one slice, so one part
‫or one domain of the state will be the menu
‫one will be the cart and one will be the order,
‫because all of these different features will of course
‫require some data, so some state in order to work.
‫Now the way in which we actually manage each
‫of these state slices will depend on what type of state
‫each of them actually is and so let's classify each of them.
‫So the first one is going to be simply global UI state,
‫so here we don't need any accounts and so therefore
‫this data will simply stay in the application
‫and needs to be accessible to many different components
‫in the tree and again, we will see this later in practice.
‫This is just so that we can take our technology decisions
‫based on what kinds of state we have,
‫so what types of state.
‫But anyway, next up the menu is going to be global
‫remote state because remember that the menu
‫is actually gonna be fetched from an API.
‫Next up, again, since this is a very simple application
‫the cart will simply be global UI state, just like the user.
‫So this data will also simply be stored in the application
‫and not in some kind of remote database,
‫so there is no API in this case.
‫And finally, the order will again be global remote state
‫because this one of course needs to be submitted to an API
‫and also fetched from an API.
‫So essentially the menu and the orders are remote state
‫because they live on a server while the user and the cart
‫are simply stored in the application.
‫And again, like I just said earlier many times
‫you will only take these decisions while you are
‫already building the application and so it's not
‫always going to be this linear process,
‫but here we wanted to do this because based on this
‫we are now going to take our tech decisions.
‫So we are going to select our technology stack
‫to build this application and so let's start actually
‫with routing.
‫So for routing, we are going to use the standard
‫for React single page applications, which is React Router.
‫Next up, we need to take a decision regarding
‫to styling the application and so this is where
‫the controversial part is going to start,
‫because here we actually want to use Tailwind CSS.
‫So Tailwind is a very trendy way of writing CSS
‫that's becoming really, really popular and so many people
‫want to learn that and so that's why we are going to go
‫with this technology for this application.
‫Next up, let's talk about state management
‫and remember how we have two different types of state
‫so UI state and remote state and so we are going to need
‫two different ways of managing that state.
‫Starting with remote state management, we will actually use
‫the new data fetching capabilities of React Router.
‫So since version 6.4, React Router is now able
‫to fetch data right inside of React Router
‫and so this is something that is really worth exploring
‫because this allows us to implement a so-called render
‫as you fetch approach instead of the fetch on render
‫that we have been using up until this point.
‫And of course, we will learn what each of these strategies
‫actually means once we start using React Router in practice
‫for this.
‫Just notice that this is not really state management
‫in a classical sense because it doesn't really persist state
‫in a place that is easy to access from everywhere.
‫But again, it's still worth exploring this new
‫and modern option because it allows us to do so many things
‫using just one library and it's also quite a nice way
‫of working as you will see soon.
‫Now finally, we also need to talk about UI state management
‫and so for that, we will bring back Redux.
‫So this state that we're going to manage is a bit complex
‫and so let's bring back Redux, because it has
‫many advantages for this kind of state.
‫And also in this case we actually want to practice Redux
‫a bit more in a real world setting and so that's why
‫I decided to include Redux in the tech stack
‫of this application.
‫So just notice that I'm not advocating for this
‫particular technology stack, so of course
‫we could have chosen completely different libraries here
‫but this is just some technology that we want to learn more
‫and to explore in this project.
‫But for example, for remote state management
‫I really highly prefer React Query instead of React Router,
‫but again here we just want to explore
‫these different technologies and so this is going to be
‫our tech stack.
‫And so this really has been enough talking now
‫and so let's finally go back to code
‫and actually start building our application based on
‫all the planning that we just did in this long lecture,
‫so I hope to see you there very soon.