如何正確的(?)利用 Vue.mixin() 偷懶

前言

最近開發的頁面以及功能大都以表格爲主，接口獲取來的 JSON 數據大都是須要通過處理，好比時間戳須要轉換，或者狀態碼的轉義。對於這樣的問題，各大主流框架都提供了相似於過濾的方法，在 Vue 中，通常是在頁面上定義 filter 而後在模板文件中使用 | 進行處理。

這種方法和之前的遍歷數組洗數據是方便了許多，可是，當我發如今許多的頁面都有相同的 filter 的時候，每一個頁面都要複製一遍就顯的很蛋疼，遂決定用 Vue.mixin() 實現一次代碼，無限複用。

最後，還能夠將全部的 filter 包裝成一個 vue 的插件，使用的時候調用 Vue.use() 便可，甚至能夠上傳 npm 包，開發不一樣的項目的時候能夠直接 install 使用。（考慮到最近更新的比較快，遂打包上傳這步驟先緩緩，等版本稍微穩定了以後來補全）

正文

閒話說夠，開始正題。

Vue.mixin 爲什麼物

學習一個新的框架或者 API 的時候，最好的途徑就是上官網，這裏附上 Vue.mixin() 官方說明。

一句話解釋，Vue.mixin() 能夠把你建立的自定義方法混入全部的 Vue 實例。

示例代碼

Vue.mixin({
  created: function(){
    console.log("success")
  }
})

跑起你的項目，你會發如今控制檯輸出了一坨 success。

效果出來了意思也就出來了，全部的 Vue 實例的 created 方法都被改爲了咱們自定義的方法。

使用 Vue.mixin()

接下來的思路很簡單，咱們整合全部的 filter 函數到一個文件，在 main.js 中引入便可。

在上代碼以前打斷一下，代碼很簡單，可是咱們能夠寫的更加規範化，關於如何作到規範，在 Vue 的官網有比較詳細的 風格指南 能夠參考。

由於咱們的自定義方法會在全部的實例中混入，若是按照之前的方法，不免會有覆蓋原先的方法的危險，按照官方的建議，混入的自定義方法名增長前綴 $_ 用做區分。

建立一個 config.js 文件，用於保存狀態碼對應的含義，將其暴露出去

export const typeConfig = {
  1: "type one",
  2: "type two",
  3: "type three"
}

再建立一個 filters.js 文件，用於保存全部的自定義函數

import { typeConfig } from "./config"
export default {
  filters: {
    $_filterType: (value) => {
      return typeConfig[value] || "type undefined"
    }
  }
}

最後，在 main.js 中引入咱們的 filters 方法集

import filter from "./filters"
Vue.mixin(filter)

接下來，咱們就能夠在 .vue 的模板文件中隨意使用自定義函數了

<template>
  <div>{{typeStatus | $_filterType}}<div>
</template>

包裝插件

接下來簡單應用一下 Vue 中插件的製做方法。建立插件以後，就能夠 Vue.use(myPlugin) 來使用了。

首先附上插件的 官方文檔。

一句話解釋，包裝的插件須要一個 install 的方法將插件裝載到 Vue 上。

關於 Vue.use() 的源碼

function initUse (Vue) {
  Vue.use = function (plugin) {
    var installedPlugins = (this._installedPlugins || (this._installedPlugins = []));
    if (installedPlugins.indexOf(plugin) > -1) {
      return this
    }

    // additional parameters
    var args = toArray(arguments, 1);
    args.unshift(this);
    if (typeof plugin.install === 'function') {
      plugin.install.apply(plugin, args);
    } else if (typeof plugin === 'function') {
      plugin.apply(null, args);
    }
    installedPlugins.push(plugin);
    return this
  };
}

很直觀的就看到他在最後調用了 plugin.install 的方法，咱們要作的就是處理好這個 install 函數便可。

上代碼

config.js 文件依舊須要，這裏保存了全部狀態碼對應的轉義文字

建立一個 myPlugin.js 文件，這個就是咱們編寫的插件

import { typeConfig } from "./config"

myPlugin.install = (Vue) => {
  Vue.mixin({
    filters: {
      $_filterType: (value) => {
        return typeConfig[value] || "type undefined"
      }
    }
  })
}
export default myPlugin

插件的 install 函數的第一個參數爲 Vue 的實例，後面還能夠傳入一些自定義參數。

在 main.js 文件中，咱們不用 Vue.mixin() 轉而使用 Vue.use() 來完成插件的裝載。

import myPlugin from "./myPlugin"
Vue.use(myPlugin)

至此，咱們已經完成了一個小小的插件，並將咱們的狀態碼轉義過濾器放入了全部的 Vue 實例中，在 .vue 的模板文件中，咱們可使用 {{ typeStatus | $_filterType }} 來進行狀態碼轉義了。

結語

Vue.mixin() 能夠將自定義的方法混入全部的 Vue 實例中。

本着快速開發的目的，一排腦門想到了這個方法，可是這是不是一個好方法有待考證，雖然不是說擔憂會對原先的代碼形成影響，可是全部的 Vue 實例也包括了第三方模板。

本文能夠隨意轉載，只要附上原文地址便可。

若是您認爲個人博文對您有所幫助，請不吝讚揚，點贊也是讓我動力滿滿的手段 =3=。

待完善

發佈 npm 包

新增項

在 v-html 中騷騷的使用 filter （2018年05月28日）

最近碰到一個問題，也是關於狀態碼過濾的，可是實現的效果是但願經過不一樣的狀態碼顯示不一樣的 icon 圖標，這個就不一樣於上面的文本過濾了，上文使用的 {{ styleStatus | $_filterStyleStatus }} 是利用 v-text 進行渲染，若碰到須要渲染 html 標籤就頭疼了。

按照前人的作法，是這樣的，我隨意上一段代碼。

...
<span v-if="item.iconType === 1" class="icon icon-up"></span>
<span v-if="item.iconType === 2" class="icon icon-down"></span>
<span v-if="item.iconType === 3" class="icon icon-left"></span>
<span v-if="item.iconType === 4" class="icon icon-right"></span>
...

不！這太不 fashion 太不 cool，我本能的拒絕這樣的寫法，可是，問題仍是要解決，我轉而尋找他法。

在看 Vue 的文檔的時候，其中一個 API $options 官方文檔 就引發了個人注意，我正好須要一個能夠訪問到當前的 Vue 實例的 API，一拍腦殼，方案就成了。

首先，仍是在 config.js 文件中定義一個狀態碼對應對象，這裏咱們將其對應的內容設爲 html 段落。

export const iconStatus = {
  1: "<span class='icon icon-up'></span>",
  2: "<span class='icon icon-down'></span>",
  3: "<span class='icon icon-left'></span>",
  4: "<span class='icon icon-right'></span>"
}

接着，咱們在 filters.js 文件中引入他，寫法仍是和之前的 filters 同樣。

import { iconStatus } from "./config"
export default {
  $_filterIcon: (value) => {
      return iconStatus[value] || "icon undefined"
  }
}

重頭戲在這裏，咱們在模板文件中須要渲染的地方，使用 v-html 來進行渲染。

<span v-html="$options.filters.$_filterIcon(item.iconType)"></span>

大功告成，之後須要根據狀態碼來渲染 icon 的地方均可以經過這個辦法來完成了。

事實證實，懶並不必定是錯誤的，關鍵看懶的方向，雖然本篇博客寫的標題是 偷懶 ，但其實我只是對於重複性的無心義的搬運代碼而感到厭煩，在尋找對應解決辦法的時候但是一點都沒偷懶，相反的，在尋求更快更好更方便的方法的時候，我逐漸找回了當初敲代碼的樂趣。