Only from the design concept, the use of the point of comparison, does not involve the implementation principle.

Uvu also said that VUEX absorbed Redux’s experience, giving up some features and making some optimizations at the cost of only being able to work with VUE.

Redux is a pure state management system, and React uses react-Redux to combine it with the React framework.

VUEX and React-Redux: One is a vUE-optimized state management system, and the other is just a combination of the general state management system (Redux) and the React framework. In addition to their regular state management functions, they will certainly have some better features for their respective frameworks, and There are some derivative projects for React-Redux. DVA is a framework based on react-Redux encapsulation and provides some optimized features. Therefore, DVA will be used for comparison in the following sections.

Design Concept:

Although many articles say not to use state management for the sake of using state management, state management is the essence of the management ideas for front-end single-page applications:

  • A Web application is a state machine, and there is a one-to-one correspondence between views and states.

In my opinion, once this pattern is accepted and state management is used in the project team, it should be strictly applied throughout the application. Therefore, based on this feature, we need a mechanism or framework that allows us to manage state, sense change, and map state to page representation.

Redux, itself is a simple state manager. We do not trace its history. From the perspective of usage, it provides a global object store, which contains the state object to contain all application data, and the Store provides some reducer methods. These methods can be customized so that the caller can change the value of state. The value of state is read-only only. If you need to change it, you must go to reducer only.Redux Tutorial part 1: Basic Usage With state preservation and read and write mechanism, Redux, a state management framework, is available to the idea of state machine management for Web applications.

React-redux, in a nutshell, provides interfaces that combine Redux’s state with React’s component presentation for one-to-one mapping between state and view.

VUEX takes the ideas of Redux and optimizes the web application development model and VUE framework. So in addition to implementing the idea of full Redux, it also has functionality similar to framework binding in React-Redux for integration with the VUE framework (although the exact usage may vary), as well as some more useful features, described below.

DVA encapsulates React-Redux, combines with middleware such as Redux-Saga, and uses model concepts, which is equivalent to optimizing Web application development on the basis of React-Redux. (I think the developers of the DVA framework might have learned something from VUEX)

So it looks like a VUEX from the VUE family can match the React family’s encapsulating and encapsulating…

VUEX data flow diagram

DVA data flow diagram

Contrast:

Because VUEX can compete against many, the following three aspects will be analyzed

  • Redux vs VUEX
  • React-Redux vs VUEX
  • DVA vs VUEX

I

Redux
  • Core object: Store
  • Data store: state
  • Status update submission interface: == Dispatch ==
  • Status update submission parameters: ==Action== with type and payload
  • State update calculation: == Reducer ==
  • Limitations: Reducer must be a pure function and does not support asynchrony
  • Features: Middleware support
VUEX
  • Core object: Store
  • Data store: state
  • Status update commit interface: ==commit==
  • Submission parameters for status updates: mutation with type and payload == Submission object/parameter ==
  • Status update calculation: ==mutation handler==
  • Limitation: mutation handlers must be non-asynchronous methods
  • Features: Support for cached getters to get the value of state after some calculation
Comparative analysis of Redux vs VUEX

Store and State are basic concepts that VUEX does not change. In fact, VUEX does not change the whole framework idea at all, except that some contents have changed their names or names in order to distinguish themselves in some details.

  • VUEX weakens the sense of existence of Dispatch. VUEX thinks that a state change is triggered as a “commit” and is invoked by the framework providing a COMMIT API to commit.
  • VUEX removed the concept of Action from Redux. Unlike Redux, which believes that a state change must be triggered by an “action”, VUEX only believes that mutation is needed to trigger a state change at any time. A Redux Action must be an object, whereas VUEX assumes that it only needs to pass the necessary parameters, with no form requirement.
  • VUEX also weakened the reducer concept in Redux. Reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer reducer In VUEX, the equivalent is mutation, or “transformation,” which simply “transforms” the old state based on the input parameter.

In general, VUEX makes the framework easier to understand by weakening the concept without actually cutting anything down.

In addition, VUEX supports getters and runs with caching, which is a bit of an optimization for improving performance. It also encourages people to use getters more.

II

React-Redux
  • State injection component: == Component combines connect method ==
  • == container component: A component that associates state with CONNECT and is passed into the Dispatch interface ==
  • Display component: not directly related to state or Dispatch
  • Features: Connect supports the mapStatesToProps method for custom mapping
VUEX
  • State injection component: == vue. use(Vuex) Applies the Vuex as a global plugin and passes the Store object to the root Vue instance ==
  • == container components: there is no such thing as ==
  • Display components: Get this.store.state.∗, also this.store.state.*, also this.store.state.∗, also this.store.mit (), and so on
  • Features: VUEX provides methods such as mapState, mapGetter, and mapMutation to generate mappings between store properties and component properties
React-redux vs VUEX comparative analysis

Through the larger differences in the way of use, the difference in philosophy can also be seen.

  • And the way components are combined. Through the use of the VUEX global plug-in, combined with the process of passing store to the root instance, VUE allows store objects to exist at run time in any VUE component. React-redux, on the other hand, requires that in addition to being used in the outer component structure to fetch the store, the container component is explicitly specified, wrapped with connect. In this way, I think VUE is more likely to recommend using store internally for every component in a VUEX framework, whereas React-Redux offers free choice. VUEX does not require the use of outer components, nor does it require a wrap of components like Connect. I think the starting point is probably to avoid verbose.
  • Container component differences. While React-Redux promotes the best practice of separating container and presentation components, VUEX makes no distinction and is all about presentation components. In my opinion, the react-Redux approach is clearer, more mandatory and normative, while VUEX’s approach is simpler and easier to understand.

Basically, it’s a matter of who covers who and who sticks in who. After all, Redux is independent of React state management, and its combination with React requires a wrapper around the React component. VUEX is tailor-made for VUE, works as a plug-in and with inserts, and offers great flexibility.

III

DVA
  • Partitioning module: Provides the concept of a Model, a model is like a small piece of a store, and DVA is responsible for integrating these small pieces into a global store without the concern of the developer. Each Model provides configuration namespaces for ease of use.
  • Asynchronous method invocation: ==effect==. Because of the redux-Saga wrapper, DVA supports configuring the Effect method as part of the Model. Each effect method is a Generator function that synchronizes asynchronous method calls (Promise), and the framework provides iterators that are executed sequentially. With wrapping, developers can call actions from Dispatch in the same way that they call the Effect method from reducer. Effect internally provides apis for users to obtain parameters, obtain state, call other reducer, and so on.

DvaJS entry, quick start Dva

VUEX
  • Partitioning modules: Allows partitioning of stores into modules, similar in concept to DVA. Like DVA, it provides access to its own state and global state, a way for components to use namespace/module names, dynamic registration, module reuse, and so on.
  • Asynchronous method invocation: ==Action==. Action is similar to mutation, but it internally supports asynchronous calls. It cannot change state directly, but mutation can be called using context.mit (). For developers, unlike DVA, which calls effects and reducers in the same way, actions in VUEX need to be called using another API– Dispatch interface. It can return a Promise object for subsequent processing by the caller.
  • Features: Supports bidirectional binding
Comparative analysis of DVA vs VUEX

They split the Store into modules for the same reason, which is necessary for large-scale application development. And the idea of modularity is the same. But asynchronous method calls are different:

  • DVA tends to support synchronous code writing and execution. The benefit is that developers feel the same when using Effects and reducers. Developers can avoid using promises with minimal exposure to asynchronous concepts, but need to embrace the novelty of Generator methods. I don’t think the cost of learning has been reduced. Maybe the benefit is that the final code is simpler and the error rate is lower. Of course, this introduces some complexity to the framework itself.
  • VUEX tends to distinguish between asynchronous methods. Action is an asynchronous method and mutation is a non-asynchronous method. There are obvious differences between how to declare, how to call, how to enter, and so on. This has the advantage of reminding developers of the need to differentiate between asynchronous methods and using promises as a regular feature.

Another feature of VUEX is the bidirectional binding of its form-class components. When combined with VUEX, binding to state in VUEX is also supported.

VUEX’s asynchronous method commits by “dispatch an Action”. This is conceptually consistent with status update commits in Redux. As can be seen from the VUEX data flow diagram, VUEX also recommends that only actions be exposed externally for invocation. As a result, VUEX is closer to Redux in use.

In general, I think DVA and VUEX are definitely learning from each other, and there is no advantage or disadvantage in the use of asynchrony. It is also perfectly possible to find or package a React-Redux middleware to use a similar purely asynchronous approach in React; It can also be developed based on VUE and VUEX so that it can support Generator and even async functions to synchronize asynchronous code writing.

— — — — — — — —

Copyright: Hyupeng1006. This article is published BY CSDN under CC 4.0 BY-SA copyright. The original link: blog.csdn.net/hyupeng1006…