I mentioned previously that we will be leveraging Google Firebase to provide the back-end for our application. In this post we set ourselves up to use Firebase and we will get started wiring up Firebase Authentication.
We will continue from where we left off in the last post. We setup some basic navigation. In this post we will explore how to adjust navigation based on who is logged in - a regular user or and administrator.
Our menus will only be seen once a user has logged in. This is, if a user is not logged in they will have access to the login, register and forgot password screens and nothing else. We will create two different sets of routes depending on whether a user is logged in, and, if logged in, we will wrap our routes in a container that holds our top level navigation.
In this post we will start to put together our navigation strategy for the application. We will use various components from Semantic UI React to drive navigation, primarily menus, in coordination with React Router.
Semantic UI React Menu - https://react.semantic-ui.com/collections/menu/
If you are joining this blog series on this post you should review the previous post. In fact, you likely will need to review the whole series for any of these posts to make sense.
In post 4 (Testing) we established a testing strategy for our app that leveraged Enzyme. In post 6 (Lazy Loading) we decided to upgrade to React 16.7 (alpha) to take advantage of (and to experiment with) some of the new features of React. This broken out tests, per https://github.com/airbnb/enzyme/issues/1917. As a result, we decided to move away from Enzyme and move to react-testing-library.
Lazy loading, or code splitting, is simply the practice of splitting an app into smaller chunks so that the whole app does not need to be loaded at once. We then only delivery chunks of code as the user requires them. This results in the app taking less time to load, which improves user experience.
Various techniques have been used in React to provide this capability. Most recently, in React 16.6, React added lazy and Suspense, which provide the most recent mechanism for code splitting.
Our application is going to use React Router (https://github.com/ReactTraining/react-router). I think of React Router as the defacto standard for routing in React. It is currently at version 4 and is well used and respected by the React community.
The one other option I have looked at briefly is Reach Router (https://github.com/reach/router). To save time I am going to stick with React Router because I have some experience with it but Reach Router looks to have gained a bit of traction with key members of the React community and is another viable option.
I am going to replace the testing framework outlined in this post in a subsequent post (7. Media Library). The information outlined here is still relevant. The part that gets replaced is Enzyme (and its dependencies). You may want to skip the Walk Through, or if you prefer you can follow the Walk Through and we will eventually uninstall the Enzyme bits. The reason for this change is explained in subsequent posts.
I am going to assume we all agree on the merits of testing. My goal is 100% automated test coverage with any project. We will probably take a few shortcuts in this project and not test everything (or, at least not test everything as deeply as we may want). In keeping with our "move quickly" philosophy the tests will probably remain light until something indicates further investment in testing is warranted. For example, if a bug is reported, I will often fix the bug and try to write a test that would have uncovered the bug.
We have some basic requirements when it comes to styling our application.
The look and feel of our application, and even the usability, may need to change in time. So, we will make choices that focus on moving quickly, and adjust in the future if required.
I am using Create React App to bootstrap the application. The will be a few purists out there that frown on this but they need to get with the times. The purists would opt for more control, better "understandability", etc. At this point in time I can't imagine their are many people out there that don't believe Create React App is a solid way to bootstrap your React application. It provides a tremendous amount of value. It saves me from writing a ton of code. This is directly in line with my philosophy - if there is a good tool available that saves time, use it.
If you are using Create React App, I recommend you don't use it blindly and that you read (and follow) the user guide: https://facebook.github.io/create-react-app/ . The guide is excellent and very useful. It provides some very useful direction for things like testing, styling, code formatting, etc.
I am going to be using Visual Studio Code as my code editor. This seems like the most popular choice these days and I have been using it for quite a while and like it. I am a bit of a dinosaur and still run Windows. If you do use Visual Studio Code on Windows, make sure you always Run as Administrator - it will reduce the number of weird errors you get. I am going to walk through my particular setup in more detail below.
I am going to be using Git/Github as my repository and for code sharing. For writing public code I don't think there is really another choice (to be clear, there are other choices but Github is the defacto standard). Although, I like Github a lot, I actually use Azure DevOps (recently rebranded from Visual Studio Team Services) on private projects and like it a lot for small teams too. I have also worked with GitLab but I found it a bit needlessly complex. Any of the commercial offerings from folks like Atlassian would work great, but would be overkill (both in terms of features and cost) for what we are doing here.