DI-aware middleware

[e-schultz]

Looking into using redux/ng-redux with a new Angular application I'm working on.

Being able to register middleware with Redux seems really promising, but was having a difficult time getting my head around how to make the middleware be able to leverage Angular's DI - more for core services like $http

For example, the api-middleware, but being able to use $http instead of fetch.

[wbuchwalter]

I'm working on that, but it will probably be a breaking change:
Currently you pass the created store in the provider phase (so before $http or any service is accesible) to $ngRedux.
I will need to change that so that ngRedux accepts a reducer + middlewares + storeEnhancer, and create the store itself in the service phase.
If you have a better idea i'm all hear :)
It should be done tonight or tomorrow, in the mean time you could do something like this (create async action) with a reducer similar to this one and using it like this (it's in TypeScript).

[wbuchwalter]

New usage:

 angular.module('app', ['ngRedux'])
  .config(($ngReduxProvider) => {
      let reducer = redux.combineReducers(reducers);
      $ngReduxProvider.createStoreWith(reducer, ['promiseMiddleware', loggingMiddleware]);
    })
   .factory('apiMiddleware', ($http) => {
      return (next) => (action) => {
        // your middleware code
      };
    })

So unlike before, you pass the reducers and an array of middleware to createStoreWith, and ngRedux will create a new store based on that.

Note that the middleware array accepts strings (and will resolve them with angular, allowing DI) or direclty functions (no need to create a factory for a middleware with doesn't need DI ) as members.

This is not yet merged, see #PR5, I'm waiting to know if that would fix your issue or if you see any problem with this approach.

Thanks!

[wbuchwalter]

fixed in #5.
I published it under 1.0.0-rc version on npm.

[e-schultz]

👍 thanks a bunch