File Structure and Mock APIs
We'll cover the following...
In UI Layout and Project Structure, we built up a hardcoded initial UI layout for Project Mini-Mek using Semantic-UI-React, added a tab bar component controlled by Redux, and started using a “feature-first”-style folder structure for our code. In Using Redux-ORM, we saw how to use Redux-ORM to manage relational data in a Redux store. Now we’ll put those pieces into practice. In this section, we’ll prepare the app for feature development, define data models with Redux-ORM, use those models to load data into the store and display it, and add the ability to track which items are selected.
Making File Structure Consistent
As described previously, we’re using a “feature-first” folder structure. However, not all the code qualifies as a “feature”. There’s really three main divisions: common code that’s generic and reused throughout the application, code that’s specific to a feature, and the application-level code that ties those features together.
We’ll do some more file shuffling to reflect those concepts:
Commit d5a218f: Move core project files to /app for consistency
After the move, the project file structure now looks like this:
- src
- app
- layout
- App.js, App.css
- reducers
- rootReducer.js
- store
- configureStore.js
- common
- components
- utils
- features
- mechs
- pilots
- tabs
- unitInfo
- unitOrganization
- index.js
Extracting Components in Features
The original UI layout we made in Part 4 has a single component for each of the tab panels. It also has fake data hardcoded right into the UI layout itself. That’s not going to work well when we start dealing with actual data. So, before we can work with data, we should extract ...