How can I prepare for Redux?

Have some feature-work that needs to get done now? Don't have time to go full-Redux just yet? Here are some guidelines we recommend if you'd like to write your code with an eye towards Redux portability.

We’ve prepared this document for the purpose of helping teams understand how to write Redux-portable code with regards to 18.0 feature work. These are simply guidelines, but the more closely they are followed, the easier the transition will be down the road:

• Use the container component pattern

  • The Ember container component pattern is directly ported from the Redux communities efforts to keep components as dumb as possible. This helps refactor-ability in general, but also lends itself towards a pretty neat refactoring to Redux down the road.

• Use route actions as much as possible for async code

  • The more centralized you keep your effectful code (including logic that deals with promises which are inherently stateful) and mutative code, the easier it will be to take that same state mutation code and transfer it to a Redux reducer function and/or saga.

• Don’t use `this.get`

  • This will keep changes to your view/component layer relatively light. We’ll be introducing a getter function that traverses relationships “tracked” by redux-query with the same signature and behavior as Ember.get/Lodash.get

• Load all your data up front (sideloading)

  • In keeping with using route actions as much as possible for async code, try also to fetch your data dependencies with as few queries as possible fromyour route’s model hook(by sideloading data) instead of relying on Ember’s lazy-loading behavior.

  • We won’t support lazy-loading/n+1 queries out of the gate (or possibly ever).

• In general, try to write code as if Javascript data structures were immutable-only

  • If using a lodash method, try to choose an immutable alternative.