Specific use of Redux in Polymer and Vue

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

In the article, I omitting the description of the configuration of redux integration with polymer and vue , as well as the description of the basics of redux itself, so I do not want to reveal this topic in the article.

0. Introduction

First, recall one of the basic principles of redux :

An object describing what happened.

On the basis of it, it is clear that we cannot directly change the state, and we can only do this through the action dispatch after the onset of the required event.

Schematically, this can be represented as:

As you can see there is a one-way data stream.
')

1. Native controls

polymer

A very handy thing in polymer when redux with redux duck is a one-way binding .

template :

 <input value="[[propFromReduxStore]]" on-change="changeText"></input> 

js-code :

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

Therefore, with input everything is basically standard: at the change event, the action dispatcher and after that the modified value falls into propFromReduxStore and the control is re-rendered with a new value.

vue

C vue slightly different situation, it does not have such a one-sided binding, as in a polymer . But similar functionality can be achieved through the sync modifier.

UPD: Thanks to mayorovp for the tip: in fact, no .sync is needed. Concerning a binding: v-model gives a bilateral binding, and just: value - one-sided. Therefore, in the example below, no .sync is needed.
template :

 <input :value="propFromReduxStore" @change="changeText"></input> 

js-code :

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

The rest is all as in the version with the polymer .

2. Components

With components it is more difficult, since it is a combination of methods, events, "wrapped" in the layout of html elements as a template.

Schematic description of the component:

As we can see about the event of a component, we will know everything after the fact, which contradicts the redux principle described above. And in order to avoid a non-consistent situation, when the control has already been re-rendered due to its internal state, and the model model has not yet changed through action and does not correspond to this view, it is necessary to take additional actions to block the direct change of state.

polymer

For example, the component paper-checkbox

template :

 <paper-checkbox checked="[[propFromReduxStore]]" on-tap="changeCheck"></paper-checkbox> 

js-code :

 changeCheck: function(e) { //     // bubbling ,        e.stopPropagation(); this.dispatch("setChecked", !this.propFromReduxStore); } 

vue

By the example of the el-checkbox component

template :

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

 <el-checkbox :value="checked" @change="changeCheck"> </el-checkbox> <el-checkbox :value="checked" @click.prevent.stop.native="changeCheck"> </el-checkbox> <el-checkbox v-model="checked" @click.prevent.stop.native="changeCheck"> </el-checkbox> 

js-code :

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

The component may not even have a click event, and if there is, then we will know about its occurrence after the fact, not to mention its surrender, but there is a native modifier that allows access to all possible native events . There is also a stop and prevent modifier , which even allows us not to write e.stopPropagation () and e.preventDefault () , as was the case with the 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 up the data-workflow along the path we need.

React did not consider, because in practice it did not use, except for jsx templates in vue , but this is absolutely not the case. But still, as far as I heard from colleagues, there are no such problems, in view of the internal architecture of event handling.