Dependencies

In addition to the Redux core library, we have chosen the following dependencies from the Redux ecosystem for use across all Tidepool's Redux applications to handle various common use cases:

* = In development only.

Dev Tools

Middlewares

  • * redux-logger to log actions as well as previous & resulting states in the JavaScript console
  • redux-thunk for asynchronous and/or conditional dispatching of actions
  • client-side routing middleware via syncHistory from react-router-redux 3.x
  • [planned] redux-worker-middleware for management of communication between the main app and one or more Web Workers through redux actions

Misc

  • react-redux for the official React bindings for Redux
  • react-router-redux 3.x for integration between the Redux store and client-side router state (see Blip's usage of React Router for details)
  • react-addons-update for ensuring that state transformations performed in our reducers don't mutate existing state but rather create new objects, etc. as necessary, essentially mimicking immutable data structures

NB: The integration between Redux and React Router has probably been the fastest moving component of the React + Redux ecosystem (and probably the seat of the most controversy), and we are already(!) out of date. The 4.0.0 release of react-router-redux has introduced radical breaking changes. We will likely update at some time in the near(ish) future.

Testing

  • babel-plugin-rewire for dependency injection into ES2015/ES6 modules (and, more specifically and most commonly in our Redux work, mocking API calls via "rewiring" the API wrapper that is passed through props (in blip) or as part of the initialization of the async action creators (in the uploader)) [Sidenote: babel-plugin-rewire essentially provides the same functionality, although via a different API, as rewire does for ES5 JavaScript, which we also have as a dependency in our client web applications.]
  • redux-mock-store for testing asynchronous and conditional action creators (i.e., "thunks"; see this recipe from the Redux docs)
  • our own tidepool-standard-action, essentially our own maintained fork of flux-standard-action with the major (and for us, crucial) difference that a "Tidepool standard action" (TSA) includes a payload in an error action
  • our own object-invariant-test-helper, a fork of the redux-immutable-state-invariant development middleware, with API changes to focus on our use case of testing that none of our array or object reducers mutate the array or object but rather return a new array or object in every instance

results matching ""

    No results matching ""