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

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.

Answer 2

I haven't found any references about "bubble up" events to top components in ngrx/example-app. Also on Rob's talks I haven't get that (I might missed something).

I'm just using all ngrx as in example and right now it seems fine. ngrx/store to store data, ngrx/effects to chain actions (as I can simplify), and "middleware" in image of 'actions' that describing everything that you are able to do with one of the store part.

And then when it seems the most convenient I'm using action (I just making sure that all actions used in file are relevant to current class).

Answer 3

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 4

I would like expand on the given answers.

When it is said that not dispatching actions from dumb components helps re-usability, apart from allowing you to use the same component you just created again and again, it helps you integrate with 3rd party components. Those might be open-source components, or even a component that your co-worker, which is unaware of the way you manipulate data with NgRx, might develop. This way, you keep your code generic, modular, and implementation-independent as much as possible.

Just to clarify, this is all about advices, and in some cases it might be smarter to act differently, but it's usually best to stick to the conventions.

Answer 5

One of the primary reasons is re-use.

In terms of MVC, think of your smart component as your controller and your dumb component as your view.

Imagine a dumb component that renders an edit form for one of your entities (model). The dumb component handles displaying the form and validation messages, however you may re-use that component on the add-entity screen, the edit-entity screen, and maybe a pop-up dialog somewhere else in the application for example. Each of these use-cases need the same form with the same validation, but you're likely performing very different actions on "submit". The smart component that invoked the dumb component is likely a different smart component in each case. By raising the event and passing the values up to the smart component you can perform vastly different actions while only coding your "view" once.