Search code examples
angularreduxngrxevent-delegationtradeoff

Redux / ngrx/store architecture: why not dispatch actions from dumb components?


I'm building an Angular 2 ngrx/store application and trying to understand best practices.

  • I love having an immutable state that changes only based on dispatched actions so that the app state is very clear and debug-able.
  • I love one-way data flow down from "smart" containers since this allows us to use the async pipe to do less checking of state.

But I don't understand why we would want to "bubble up" events from dumb components all the way up to smart components before dispatching an action to the store. Is the only reason to have re-usable components? It seems to me that most components aren't re-used anyways cause there aren't many situations when I would want to have everything identical including the CSS. Are there any other benefits I'm missing? From the point of view of maintainability / readability, isn't it nicer to be able to just see the action dispatched right at the component where the interaction is happening?


Solution

  • I totally agree with you and I have the same doubt.

    I expect the component to emit an action using the dispatcher (which for ngrx/store is the store itself) instead of moving this logic to the container (the actual application).

    This way the component is decoupled from the container and the container doesn't need to know about actions: it will just listen to the state change and pass down the eventual data, if necessary.

    On the other hand, the Introduction to ngrx/store is promoting the design with a smarter container, which knows a lot about the underlying components.

    Frankly, I can't yet see a clear winner: I just think that dispatching actions from the component is simpler, cleaner, and closer to the Elm Architecture which was one of the Redux's inspirations.