Redux @ Tidepool
The Redux documentation is very well-written. If you are unfamiliar with the library, we recommended starting with the Redux Intro and Basics docs to familiarize yourself with the standard Redux vocabulary before reading more of the documentation here about our use of Redux at Tidepool.
It is also very important to read and understand the section of the Redux documentation dedicated to Normalizing State Shape. A properly "normalized" state tree—in brief: storing detail information in only one place in state for each entity that can be referenced by an ID—is very important to reap all the benefits of Redux, in particular for having confidence that for any particular piece of state, there is a single source of truth for that state in the application.
This documentation summarizes the design decisionsa that guide our usage of Redux across all our client web applications and internal dependencies at Tidepool. We expect all current and future developers at Tidepool to abide by these decisions and guidelines to the fullest extent possible in order to maintain a consistent developer experience across applications and foster a set of standards that will make maintenance, further development, and onboarding of additional developers and contributors as easy as possible.
Table of contents
We recommend reading the following documents in this order:
- our Redux-related dependencies
- custom middlewares
- directory structure & naming
- our standard for Redux actions
- our strategies for Redux testing
a. In case anyone wants to praise or assign blame, those responsible for these design decisions are largely @jebeck (Jana Beck) and @GordyD (Gordon Dent). @jebeck authored the original version of this documentation. ↩