The specifics of using Redux in Polymer and Vue

As I wrote in my previous articles, I worked with both polymer and vue in conjunction with redux . Therefore, I would like to share experience related to the specifics of using redux in these libraries. We will consider on the simplest atomic controls: native (input, checkbox) and wrapped, in the form of components of these libraries.

In the article, I omit the description of the integration settings reduxwith polymer and vue , as well as a description of the basics of redux itself, so I do not want to expand on this topic in the article.

0. Introduction

First, recall one of the basic principles of redux :

The only way to change the state is to emit an action, an object describing what happened.

Based on it, it is clear that we cannot directly change the state, and we can do this only through the action dispatch after the necessary event occurs.

Schematically, this can be represented as follows:

As you can see, there is a one-way data flow.

1. Native controls

polymer

A very convenient thing in polymerconjunction with a reduxduck is one-way binding .

template :

js-code :

changeInput: function(e) {
  this.dispatch("setText", e.currentTarget.value);
}

Therefore, with input, everything is, in principle, standard: during an event change, the action is dispatched and after which the changed value falls into propFromReduxStoreand the control is already rendered with the new value.

vue

C is a vueslightly different situation; there is no one-way binding like inpolymer . But similar functionality can be achieved through the sync

UPD modifier : Thanks mayorovp for the tip: in fact, no .sync is needed. Concerning binding: v-model gives two-way binding, but just: value - one-way. Therefore, the example below does not need .sync.
template :

js-code :

changeInput: function(e) {
  this.actionsRedux("setText", e.currentTarget.value);
}

The rest is the same as in option c polymer.

2. Components

It is more difficult with components, since this is a set of methods, events, “wrapped” in the layout of htmlelements in the form of a template.

Schematic description of the component’s operation:

As we see about the component’s event, we’ll already learn about all the facts, which contradicts the principle reduxdescribed above. And in order to avoid an inconsistent situation, when the control has already been rendered in view of its internal state, and the pinned model has not yet changed through actionand does not correspond to this representation, it is necessary to perform additional actions to block the direct change of state.

polymer

For example, the paper-checkbox

template component :

js-code :

changeCheck: function(e) { //Здесь ловим клик по компоненту
  //Предотвращаем bubbling события, что бы компонент сразу не перерендерил компонент 
  e.stopPropagation();
  this.dispatch("setChecked", !this.propFromReduxStore);
}

vue

On the example of the el-checkbox

template :

UPD component : The code below emphasizes the approach itself through native events, but for a specific control (meaning its internal architecture) there are three options:

js-code :

changeCheck: function() {
  this.actionsRedux("setChecked", !this.propFromReduxStore);
}

The component may not even have events click, and if there is, then we will learn about its occurrence after the fact, not to mention its addiction, but there is a native modifier that allows you to access all possible native events . There is also a modifier stopandprevent that will even allow us not to write e.stopPropagation () and e.preventDefault () , as it was with polymer. A little, but nice.
The whole point is that, if necessary, we can access the component’s native events and completely suppress them, and start the data-workflow along the path we need.

ReactI didn’t consider it, because in practice I didn’t use it, except for jsx-Templates invuebut it’s completely wrong. But still, as far as I have heard from my colleagues, there are no such problems there, in view of the internal architecture of event processing.