replaceMiddleware feature for use with lazy-loaded modules

[un33k]

feature

It would be great to have a feature like replaceReducer() to replace the middlewares as well.
This is extremely handy where a lazy loaded module can register its middleware and the main app can add them to the existing middlewares and call replaceMiddlware() to activate them.

What is the current behavior?
The configureStore() requires the middlewares upfront via applyMiddlware() in order to create the store. This makes the main app responsible for creating a list of middleware of all modules upfront.

What is the expected behavior?
It would be great to have the main app provide a registerMiddleware() function for modules to register their middlewares on load. The app can register the logger middleware itself, but each app will trigger its own middleware registration when loaded. In turn each call to registerMiddleware() will trigger a replaceMiddlware(). This way, splitting the code and lazy loading modules in Angular2 will work and load time of the first page will be much faster.

Which versions of ng2-redux
macOS Sierra, Node v6.0.0, "redux": "^3.6.0", angular 2.1.0 "ng2-redux": "^4.0.0-beta.0",

[SethDavenport]

AFAIK redux itself doesn't support this. Since we're a wrapper around vanilla redux, we currently don't either.

It might be possible to write a 'meta-middleware' that takes care of registering other middlewares, but I'm not sure what this would look like in practice. One of the benefits of our model is that such a thing could be done independently as its own lib and used with ng2-redux or other redux-based apps.

However, it opens the door to a lot of potential side-effects which violate some of the functional principles on which redux is built.

I'm familiar with lazy loading, having done it in React and Angular2, and it's definitely needed for large apps. However to be honest I'm not sure how much middlewares (or even reducers for that matter) contribute to the download size of a large app to begin with. In my experience it's typically UI components, framework code, and occasionally selectors that make up the bulk of the size.

I don't suppose you have an example where the middlewares take up enough size to need lazy loading?

[SethDavenport]

You might find this thread interesting: reduxjs/redux#37

[un33k]

@SethDavenport - Think of a module that has its own code-space, reducers, middlewares and is fully self-contained. It registers its reducers and middlewares on load. Simply beautiful. Just package it and use it in many projects. Sure we can have epics/actions etc. directories outside the module that are aware of the business logic of that module. But that wouldn't be the greatest way to organize the code.

I am thinking that if we already have the replaceReducer for the sake of lazy loading, then we may as well have the replaceMiddleware to go with it or our story is 1/2 complete.

We take bandwidth for granted these days, but traveling through countries where the network is spotty, saving every bit of bandwidth is important, especially for large apps with many independent modules.

I don't know the right answer here, but if there is a way to enable such a feature, it would be a great one to have.

[SethDavenport]

Middlewares are not typically part of feature modules. They are wrappers around dispatch, and dispatch is global. That's simply how Redux works. Conceptually, a middleware that only works on part of the store doesn't make much sense in my opinion.

[SethDavenport]

Think of it this way: a middleware is for a cross cutting concern. If you need module specific logic, that's better handled in a module specific epic.

[un33k]

Now got one large application with 20 lazy loading features & growing. Would have been nice if this package allowed for lazy loading epics, actions and etc. Not sure if doable as this package depends on another that doesn't provide that feature.

[SethDavenport]

redux-observable epics can be lazy loaded - I don't recall the details but I have seen it done. IIRC you register a 'root epic' that allows other epics to register with it.

actionCreators are just functions. They can be lazy loaded like anything else in angular.

reducers can be loaded lazily with .configureSubStore() or with @WithSubStore.

None of this requires lazy loading of middlewares, which is a concept that doesn't make sense.

[adamlubek]

@SethDavenport see your comment "reducers can be loaded lazily with .configureSubStore() or with @WithSubStore." - any chance for an example of this please?

[danimalia]

Yes, I would also love to see how configureSubStore() works in an example with a lazy-loaded module. There seems to be no information about this function anywhere.. How do we get to the new store once we've configured it?

I have a a lazy-loaded module that contains a fairly complex set or reducers, formatters, schema, etc. Currently, angular-cli (webpack) is putting it all in the main bundle because it all gets imported back through to the rootReducer.