A guide to the structure/patterns/best practices and philosophies of Muve's React/Redux Client Side App(s).
Base level folder. Contains app entry point, redux store creation, and routing. Within the routing the root component of the app is defined as the Main Layout, which includes the shared markup for all pages (header,footer, etc.). The size of our app does not justify packages, so therefore app/packages are combined.
Modules basically correspond to routes (Login/Tasks/Patient Details/Task History etc.)
Scenes setup the markup in/for each route, usually by calling a container with a corresponding name, unless the markup for that page is very simple (Metrics, Logout).
Containers serve as the connection between the state and the presentational components. Containers usually take two arguments that are function, mapStateToProps and mapDispatchToProps. Within the former function we use selectors to get pieces of the state for the component, you should never access state directly (e.g. state.tasks.list), the contianer should not need to know about the state's structure. Within the latter we pass actions/action creators that are usually wrapped in a dispatch call via bindActionCreators.
Components are the smallest building blocks of the app. They should be functional components whenever possible (when no lifecycle methods are called/needed, when there is no state management within the component). There should be no other functions defined within the file and there should be no functions defined within the class other than lifecycle methods. If that is the case, a helper/selector should be defined in the appropriate file/folder or perhaps if the function contians markup, a component should be created seperately for that markup.
These are High Order Components or utilities.
Redux state should only be used for large/overarching data or data that is used by other componenets. In other words, data manipulation that can be encapsulated in a singular component should be via React's state API. Each module should maintain their own state and actions.
Actions/Action Creators should avoid using getState unless it is for conditional dispath (e.g. checking cached data/authentication).
Each set of reducers/actions/action creators should be tested through the action's api (dispatching actions making sure they were fired correctly). They should be tested 100%, each branch/condition/line etc.
Response data should be formatted after the response has been successfully recieved, but before an entitity is created.
Selectors live in the reducers and should wherever possible only be making direct calls/associations to the state. Formatting/Computation of data should be done in the action creator.
HTML should be used for sematic purposes only. In other words, one should not use an h2 for it's styling, size, color etc. but because it is the second header on a page.
TBD
All code is linted according to, for the most part, the airbnb-eslint-config.
For testing we use Jest. Our testing philosophy is laid out here.