Intro​

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.

Intro​

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.

Intro​

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.

IMPORTANT!​

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.

Intro​

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.

Application Requirements​

We have some basic requirements when it comes to styling our application.

1. The application must be responsive. Our goal is to provide a usable experience on both mobile and desktop. There is no requirement (or need), at this time, for dedicated mobile apps.
2. The application is somewhat utilitarian. The look and feel of the application needs to support a good user experience but in and of itself will not attract users to the application.
3. It is not required that our application have a unique or independent look and feel. In fact, because of the utilitarian nature of our application, it will likely aid users if we follow patterns they are already familiar with in other applications.

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.

Intro​

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.

Intro​

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.

This blog series captures the creation of a new web application. The general idea of the blog series is to discuss a specific set of technologies and a particular pattern for developing a new web application. The series is not meant as a training piece on any particular technology but instead will focus on how a particular tech stack can be used to build a modern web application.