‫Welcome back.
‫So this time around, in this most real-world project
‫of the course, let's really start the project
‫by first learning about the business and the requirements,
‫and then planning out the entire application.
‫So we're gonna build an application
‫for a small boutique hotel called The Wild Oasis,
‫which features eight luxurious wooden cabins.
‫So what they need us to do is to build a custom application
‫where they can manage everything about their hotel,
‫so the bookings, the cabins, and also the guests.
‫And so this is basically an internal application
‫that this business will use inside the hotel
‫to check in the guests as they arrive.
‫So right now this business is still just building out
‫this hotel and so right now they have absolutely nothing
‫so they will also need us to build the API for us,
‫so we will need to model all the data,
‫we will have to store it somewhere,
‫and then basically the application
‫that we're gonna build will function as a back office
‫to manage the data that lives in that API.
‫And later on, they will then also want
‫a customer-facing website where customers
‫will then be able to basically book stays on their own
‫and so this will then work with the same API,
‫but again, we might do this one later,
‫but for now, this project that we're building now
‫is this internal application where the hotel
‫is basically managed everything about it,
‫so again, bookings, cabins, and guests.
‫So this is gonna be a really, really cool application
‫and so let's start planning it now very quickly.
‫And so just to review what we learned earlier,
‫this is how we can plan a React,
‫or really any other web application.
‫So first we need to gather the business requirements
‫and features that we should implement,
‫then we divide the application
‫into multiple pages and basically think about the UI
‫and how we divide everything into components,
‫and then after that, we divide the application
‫also into different feature categories,
‫so all the features from the requirements can be gathered
‫into a few feature categories
‫so just like we did before in the fast pizza application.
‫And then finally,
‫we also need to decide on our technology stack,
‫so basically we need to decide what libraries we want to use
‫in order to implement the project.
‫Now, okay, and so let's start with step number one,
‫which are the project requirements.
‫So this time around, we have a lot of requirements,
‫as you can see here, and so I want you to pause the video
‫right now and read this entire list on your own
‫so I will not waste like five minutes here to read this
‫to you because, well, you can just read it yourself,
‫so please pause the video right now
‫and then I meet you back here in a second.
‫Okay, so did you read this?
‫Well, I hope you did
‫because we will now immediately group these requirements
‫into some feature categories
‫so let's do that, not on the next slide,
‫but right here where we actually have the requirements.
‫So first up, we will have some authentication
‫in this application.
‫So these three first points are basically about logins
‫and about creating user accounts
‫and so that's all under the umbrella of authentication.
‫The next step we have the cabins features,
‫we also have bookings, and then more details.
‫Here we also have checking ins and outs,
‫so basically the users of the application,
‫which are the hotel employees,
‫will be able to check guests in and out
‫as they arrive at the hotel or on the day that they leave
‫and so that can be a different feature group.
‫Just note that all of this is of course highly subjective
‫so we might, for example, also group the bookings together
‫with the check in and checkout feature,
‫but I thought it might be better to have them separate here,
‫and in any case, this is just a quick overview here,
‫so as we implement each of these features
‫we will then come back to this list.
‫But now going on, next up we have this requirement here
‫which is about the guest features,
‫and then apparently we will also need to build
‫a huge dashboard, so here we will have all kinds
‫of statistics and of charts and so this one
‫is actually going to be a lot of fun to build
‫so this will give the application a real, real-world touch
‫so it's gonna be really cool.
‫And then finally,
‫we also need to allow the users to set some settings
‫and so that's yet another feature group.
‫All right, and so now let's move on
‫and group these feature groups into some pages.
‫So here are these feature categories.
‫So all the seven that we just identified,
‫and again, from these we can kind of easily derive
‫the pages that we are going to need.
‫And right off the bat, we can see here
‫that this application is a lot bigger
‫than the one that we had before
‫so we had so many requirements
‫and here we have so many feature categories,
‫which means that probably we will also need
‫a lot of different pages,
‫starting here with the dashboard page,
‫which will basically be the homepage of the application.
‫Then we will also need a bookings page,
‫which is where all the current bookings will be displayed,
‫and actually not just the current ones,
‫but also the past ones and the future ones.
‫Then we will have a page for displaying all the cabins,
‫which is where the users will then also be able to edit
‫and delete cabins.
‫Now, for the guests, we don't really need any page
‫because in the requirements,
‫they told us nothing about that
‫so they didn't tell us that we need a way to edit
‫or to delete guests, for example,
‫and so that means that we probably don't need to implement
‫a guest's page, while for the bookings and the cabins,
‫since there needs to be a way
‫of showing all of them and maybe deleting and editing,
‫then we need to do that somewhere
‫and so we need a page for those.
‫Now, what we also need a page for is to check users in,
‫actually, and so here we can use this check-in route
‫with the booking ID param, and then also a settings page,
‫which is where users, as the name says,
‫can define the settings, and finally,
‫we also need a signup page,
‫so a page where users can be signed up,
‫and then a login page and this login page
‫is probably going to be like our default homepage
‫in case that the user is not logged in.
‫Also notice how the user signup
‫is actually not going to happen on the page called signup,
‫but instead on a page called users
‫and the reason for that is that people
‫will basically not be allowed to simply sign up
‫to the application, instead, it will be inside of the app
‫where existing users can register new ones,
‫but of course, this will all make more sense
‫once we actually implement this.
‫And then finally, we also need a page where users
‫can update some account settings, so things like the name
‫or the avatar or also the passwords.
‫All right, and so these are, at least for now,
‫the eight pages that we are going to implement.
‫Just note that if you were to build this app on your own,
‫then you would probably not figure all of this out
‫right at the very beginning so you might do a part of this
‫in the beginning, but not all of it,
‫so things are never this linear,
‫but since this is kind of a linear video course,
‫we need to do this planning somewhere
‫and so we are doing it all here at the very beginning.
‫Also notice that the dashboard here
‫doesn't have an arrow pointing to it
‫and the reason for that is that the dashboard
‫combines multiple of the other features.
‫Great, so next up, we would typically discuss state,
‫but let's actually leave that for later
‫because most of our state will just be global, remote state.
‫And since we will also need to build the API,
‫we will discuss how we will store all this data that we need
‫for this application later when we build that API,
‫so we are going to use a really nice service
‫called Supabase for that
‫and so then we will talk about or state and/or data.
‫And so instead, let's immediately jump
‫into some tech decisions,
‫so discussing what kind of technology we will want to use.
‫So up until a few years ago, it was kind of a standard
‫that all React applications would simply be 100% rendered
‫on the client, which means that we would use React
‫to build single-page applications
‫like we have been doing all this time.
‫However, over the last few years,
‫things have been changing a bit
‫and the React team has been advocating more and more
‫for a move back to the server.
‫Now, I'm not gonna go really deep into this topic
‫at this point because we will discuss this deeply
‫in a section that it will add to the course later
‫which is going to be all about Next.js,
‫but for now, we will just talk briefly about this
‫because these days it's actually a very important
‫technology decision between using client-side rendering
‫with so-called Vanilla React,
‫so the way we have been doing it all this time,
‫or if we go with a React framework like Next.js or Remix
‫for server-side rendering and so let's just very briefly
‫go through some differences here.
‫So basically, client-side rendering with Vanilla React
‫is used to build single-page applications,
‫while with service-side rendering,
‫we typically build multi-page applications
‫and so the big difference is that single-page applications
‫are 100% rendered on the client so all the HTML
‫is basically generated right in the user's browsers.
‫The problem with this rendering on the client
‫is that it needs to be all done by JavaScript,
‫which means that this JavaScript needs to be downloaded
‫before the app can even start running,
‫which can be bad for the performance,
‫especially when the users
‫are using more of a low-end device,
‫and also if the user has a worse internet connection,
‫that can impact the performance as well
‫so here is where the main advantage
‫of server-side rendering lies
‫because with server-side rendering, the HTML,
‫or at least some of it, can be rendered on the server,
‫which means that this solution is a bit more performant
‫because a lot less JavaScript needs to be downloaded
‫to the user's devices.
‫Now, as I was saying initially,
‫the React team right now is advocating
‫more and more for this solution
‫so they are basically telling developers now
‫that server-side rendering
‫might be the way to go in the future.
‫However, this is not really true for all applications.
‫For example, one perfectly fine use case
‫for client-side rendering are applications
‫that are basically used internally as tools
‫inside some companies
‫so that are not downloaded by many users
‫so these are many times applications that are hidden
‫behind a login screen with no need
‫for search engine optimization
‫and so these are perfectly fine as single-page applications,
‫despite all the server-side rendering hype
‫and there are many applications in this category,
‫so many applications that are only used internally,
‫and so client-side rendering with Vanilla
‫or with plain React isn't going anywhere.
‫Now, again, there is a lot more to be said about this topic,
‫but this is all we need to know
‫at this point in order to decide
‫that we want to build a regular single-page application
‫with client-side rendering in this project,
‫again, because this application actually perfectly fits
‫this use case that I just explained.
‫And so now that we know that this is what we want to build,
‫it's time to assemble our tech stack again
‫and so we need to make our technology decisions right now,
‫and starting with routing,
‫here we are going to use again the gold standard
‫for single-page applications, which is React Router.
‫Next up for styling, in this project,
‫we are going to use a very popular library
‫called styled-components.
‫So this is a completely new way of writing styles
‫because we will do so right inside JavaScript,
‫so right inside or React components,
‫and this technology is used at IMDB, Spotify, Coinbase,
‫and many, many others and so it can't be a bad choice
‫and it's definitely a technology worth learning for you
‫and so that's why I included it in this project.
‫Next up, we need to talk about state management
‫and in particular about remote state management
‫because basically all the state in this application
‫will be remote state, as I was saying earlier.
‫So essentially, this application will implement
‫an easy-to-use interface to this remote data
‫that lives on the server
‫and so we will load and mutate that data a lot,
‫and so for that, we need a specialized library,
‫and that specialized library that we have talked about
‫many, many times before is React Query.
‫So in my opinion, this really is the best way
‫of managing remote state because it has many, many features
‫that work really easily out of the box.
‫So things like state caching, automatic re-fetching,
‫in many situations, pre-fetching for things like pagination,
‫offline support, and many, many more.
‫Now, as an alternative,
‫we could have used also SWR or Redux Toolkit Query,
‫which would've been quite interesting as well
‫and you could definitely learn that one after this project,
‫but since React Query seems to be by far the most popular
‫of these options, that's the one that we are going with
‫and it's also the one that I really like the most.
‫Now about UI state management,
‫since there is almost no UI state in this application,
‫we will just use the Context API for that
‫so we don't need to reach for Redux in this case.
‫Now, another library that will make our lives
‫a lot easier is a library for managing forms.
‫So there are gonna be lots of forms in this application
‫and so we can use a form management library
‫like React Hook Form
‫which will make many tasks a lot easier for us.
‫So for example, instead of having to manually create
‫state variables for each element in the form
‫and also manually handling errors,
‫we can just allow this library to take care of all of that.
‫And so these are the five main big tools that we will use
‫on the front-end application.
‫So these are all extremely popular libraries
‫and tools that many, many developers out there
‫use to build professional React applications
‫and so now you will learn how to do the same
‫and we will even use a few other tools
‫such as React Icons, React Hot Toast for notifications,
‫Recharts for displaying beautiful charts in RUI,
‫date-fns for date manipulation,
‫and finally, the Supabase library
‫as I already mentioned earlier
‫so this is where we will store all our remote state
‫and basically build an API, as you will see later.
‫So after all this talk,
‫it's now finally time to get our hands dirty
‫and so in the next lecture,
‫we will again set up our project
‫so that we can finally get started.