Vue Element front-end application development: Use of API Store View in Vuex

Overview

When we develop Vue applications, we often need to record the contents of some variables. These can be used to carry the state of the interface or to process data exchange between pages. Processing these contents can be classified as Vuex state control. For example, we often need to access backend data on the front end, usually by calling the encapsulated Web API to obtain data, and use the Store mode to handle related data or state changes, while the view View is mainly responsible for interface display processing. This essay mainly introduces how to integrate the relationship between these three to realize logical operations such as data acquisition, processing, and display.

Vuex is a state management pattern developed specifically for Vue.js applications. It uses centralized storage to manage the status of all components of an application and uses corresponding rules to ensure that the status changes in a predictable manner. For details about the differences and connections between Vuex's related State, Getter, Mutation, Action, and Module, please refer to: https://vuex.vuejs.org/zh/

1. Separation of front-end and back-end and Web API priority route design

Web API is an application interface framework that can build HTTP services to support a wider range of clients (including browsers, mobile devices such as mobile phones and tablets). ASP.NET Web API is an ideal platform for building RESTful applications on .NET Framework/.net Core. In the current developed application scenarios, we often need to access Winform clients, APP programs, website programs, and the currently popular WeChat applications, etc. These data should be provided by the same service, which is the Web API platform we need to build. Since the Web API layer is a public interface layer, we can ensure the data consistency of each interface application layer.

Since we prefer to completely separate the front-end and back-end, our back-end can be completely built and supported by Web API. We can use a unified interface platform built with .net framework or .net core, a simple Web API interface platform made of Asp.net, or a Web API platform built on the basis of ABP-aspnetboilerplate (Introduction to ABP Framework Essay).

In this way, we can build multiple front-end applications based on these API interfaces, such as Web front-end, Winform front-end, and various APP applications.

With the introduction of the VUE + Element development method that separates the front-end and back-end, the boundaries between the front-end and back-end are very clear. The front-end can build the front-end application by obtaining the corresponding JSON through the network.

In the front-end processing, the main thing is to use the Store object in the Vuex mode to implement the request processing for Action and Mutation. After obtaining the data, the data in the State state is updated. If you are only processing data for the current page, you don't even need to store the State information. You can directly obtain the returned data and update it directly to the interface view.

In the early stages of development, we don’t even need to have any relationship with the backend. We can use Mock data instead of requesting data from the Web API. As long as the Mock data structure is consistent with the JSON returned by the Web API interface, we can achieve fast docking in the later stage without affecting the existing code processing method.

2. Axios network request processing

Before we proceed further, we need to know some object concepts in Vuex and the relationship between them.

Vuex is a state management pattern developed specifically for Vue.js applications. It uses centralized storage to manage the status of all components of an application and uses corresponding rules to ensure that the status changes in a predictable manner. For details about the differences and connections between Vuex's related State, Getter, Mutation, Action, and Module, please refer to: https://vuex.vuejs.org/zh/

Before we start making network requests, we need to understand axios. Axios is a Promise-based HTTP client for browsers and nodejs. It is essentially a wrapper of native XHR, but it is an implementation version of Promise that complies with the latest ES specifications. Here we only need to know that it is a very powerful network request processing library and is widely used. Let's list a few code examples to understand it.

POST request

axios({
    method: 'post',
    url: '/user/12345',
    data: {
        firstName: 'Fred',
        lastName: 'Flintstone'
    }
})
.then(function (response) {
    console.log(response);
})
.catch(function (error) {
    console.log(error);
});

GET request

axios
  .get('http://rap2api.taobao.org/app/mock/23080/resources/search',{
      params: {
         id: 5
      }
   })
  .then(res => {
    console.log('The data is:', res);
  })
  .catch((e) => {
    console.log('Failed to obtain data');
  });

If we want to request data across domains, we need to set the proxy in the configuration file. For the vue-cli3 project, we need to write the configuration in vue.config.js.

You can set up request interception and response interception separately, and make judgments and processes before the request is sent and the response arrives at then. The general processing method is to encapsulate a class such as the request class, and then perform unified processing on the interceptor, such as adding some user identity information before the request.

// create an axios instance
const service = axios.create({
  timeout: 5000 // request timeout
})

// request request interception service.interceptors.request.use(
  config => {

    if (store.getters.token) {
      config.headers['X-Token'] = getToken()
    }
    return config
  },
  error => {
    // do something with request error
    console.log(error) // for debug
    return Promise.reject(error)
  }
)

3. Use of API, Store and View in Vuex

Let's go back to the introduction of API, Store and View in Vuex.

Let's take a look at the encapsulation of the API request call class. As shown below, we have created some API class files for operating data. Each API name corresponds to the centralized processing of a business, including list requests, single requests, additions, deletions, modifications, etc. for a specific business, which can all be encapsulated in one API class.

Let's take a look at the class file definition of Product.js as shown below.

Here I use the operation comparison of Request and Axios. The two are very similar, because request is a simple encapsulation of Axios, which mainly intercepts and injects some login information and some response error handling.

import request from '@/utils/request'
import axios from 'axios'

In the Url here, through the processing of the proxy configuration, the corresponding iqidi will be replaced with the processing of the corresponding external domain name, thereby realizing the acquisition of cross-domain processing request data. We only need to know here that the url will eventually be converted to something like

http://www.iqidi.com/h5/GetProductList You can use the actual address to make a request, and the return value is a JSON data set.

Due to the JS processing part in the Vue view, the API can be directly introduced to request data, as shown below.

import { GetProductList } from '@/api/product'

Then we can define a method to get API data in the method method.

methods: {
getlist(type) {
   GetProductList({ type: type }).then(response => {
     const { data } = response
     this.productlist = data.list
     this.listLoading = false
   })
}

This call is the most direct API call and does not introduce the Action or Mutation encapsulated in the Store module for asynchronous or synchronous processing. In general, it is simpler to use this method directly, because most page processing or component processing does not require global state storage of data, that is, there is no need to process the global Store object.

If we need to store the corresponding information globally, we need to introduce the encapsulation of API calls in the Store module, including the processing of Action or Mutation.

Let's first define the Store storage class, as shown in the following interface.

If we need to store data such as product lists in a global state, we can consider creating a module in the corresponding Store directory, such as product.js, to manage information such as Action, Mutation, and State.

import { GetProductList, GetProductDetail } from '@/api/product'

const state = {
  productlist: [],
  productdetail: null
}
const mutations = {
  SET_PRODUCT_LIST: (state, list) => {
    state.productlist = list
  },
  SET_PRODUCT_DETAIL: (state, detail) => {
    state.productdetail = detail
  }
}

const actions = {
  // Product list getProductList({ commit }, { type }) {
    console.log(type);
    return new Promise((resolve, reject) => {
      GetProductList({ type: type }).then(response => {
        const { data } = response
        commit('SET_PRODUCT_LIST', data)
        resolve(data)
      }).catch(error => {
        reject(error)
      })
    })
  },

  // Get product details getProductDetail({ commit }, { id }) {
    return new Promise((resolve, reject) => {
      GetProductDetail({ id: id }).then(response => {
        const { data } = response
        commit('SET_PRODUCT_DETAIL', data)
        resolve(data)
      }).catch(error => {
        reject(error)
      })
    })
  }
}

export default {
  namespaced: true,
  state,
  mutations,
  actions
}

Let's take a look. If the business class of the Store module is introduced, the calling code in the interface view is modified to call the corresponding Action or Mutation.

 methods: {
    getlist(type) {
      // GetProductList({ type: type }).then(response => {
      // const { data } = response
      // this.productlist = data.list
      // this.listLoading = false
      // })

      this.$store.dispatch('product/getProductList', { type: type }).then(data => {
        this.productlist = data.list
        // this.loading = false
      }).catch((e) => {
        // this.loading = false
      })
    }

We would like to emphasize here that, in general, you can use the API class call in the view module. There is no need to create a Store module class for each business module for corresponding management. Only when these status data need to be shared among multiple pages or components, consider introducing the Store module class for detailed management.

We just said that if you need to create a Store state management module for the corresponding business module, you need to create a corresponding module class, such as the product.js class file mentioned earlier.

The Vuex Store management class in the Modules directory is divided according to the business boundaries. A separate file is created for each corresponding business for management (if necessary).

In index.js, we load these classes according to different namespaces through dynamic module loading and use them uniformly.

import Vue from 'vue'
import Vuex from 'vuex'
import getters from './getters'

Vue.use(Vuex)

// https://webpack.js.org/guides/dependency-management/#requirecontext
const modulesFiles = require.context('./modules', true, /\.js$/)

// you do not need `import app from './modules/app'`
// it will auto require all vuex modules from modules file
const modules = modulesFiles.keys().reduce((modules, modulePath) => {
  // set './app.js' => 'app'
  const moduleName = modulePath.replace(/^\.\/(.*)\.\w+$/, '$1')
  const value = modulesFiles(modulePath)
  modules[moduleName] = value.default
  return modules
}, {})

const store = new Vuex.Store({
  modules,
  getters
})

export default store

The above is the detailed content of the use of API Store View in Vuex of Vue Element front-end application development. For more information about Vue, please pay attention to other related articles on 123WORDPRESS.COM!