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

Question

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?

Answer 1

First, I'm not an expert on the subject disclaimer.

• I feel that smart components controlling dumb components is actually what it is called the mediator pattern. Using this pattern ensures that fewer components have to deal with the store, thus enhancing louse coupling.
• Easy maintenance: If you have to refactor and mass rename actions it's easier to this when the action is present in fewer places.
• Having a central place that deals with actions allows for a quick overview of the architecture. Also hot-swapping of the store access logic could be done easier.
• And as it was already mentioned: reuse. You can share and reuse dumb components between projects that have or don't have ngrx architecture.
• Also reuse in the same project just by wiring different inputs and outputs. Ex: A dropdownComponent could have a lot of usecases that require different inputs and outputs.

Answer 2

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.