What Was Covered

That was a lot of information, but you made it! Hopefully you now have a better idea how some of the pieces fit together in a more realistic React+Redux application, with something bigger than yet another Todo list example.

Let’s look back at some of the things that you should now be familiar with.

Project Planning and Setup

Create-React-App is a great tool for creating a new React project that has a good build configuration, and it keeps the build process abstracted away so you don’t have to worry about it.

The Yarn package manager has an “offline mirror” feature. You can use that to save NPM package tarballs into a folder in your code repo, then commit that folder. That way, when someone else clones the repo, they get exactly the same package versions that you had, those packages can be installed faster, and the installations work both offline and across different OS platforms.

While CRA doesn’t include Redux, we can easily set up Redux in a CRA project.

We can also use Webpack’s “hot module replacement” feature to swap in new versions of files when we save changes, without having to refresh the entire page.

UI Layout and Project Structure

Semantic-UI-React is an excellent React-specific adaptation of the Semantic-UI UI toolkit. It won’t be a good fit for every application, but if you’re looking for an easy-to-use toolkit that looks good (or just want an alternative to Bootstrap), it’s a great choice.

We can control what’s being displayed in the UI by tracking “UI state”-type values like which tab is currently selected. By following the “container/presentational component” pattern, it becomes easier to change where data is coming from if you need to switch between component state, Redux, or another data store. The “presentational” component doesn’t care, it just displays UI based on the props it’s receiving from its parent.

There’s no single “correct” way to organize folders and files in a project. However, I do prefer a “feature-first” style of structure. Ultimately, you should choose whatever approach best helps people understand where specific code lives in your project.

I’m also a fan of “absolute import” paths like import TabBarContainer from "features/tabs/TabBarContainer", rather than import TabBarContainer from "../../tabs/TabBarContainer". Fixing up relative paths is a pain, so I only use relative paths if they’re one folder up at most.

It’s fine if UI state like “active tab” is stored in a React ...