Vue3.0 所採用的 Composition Api 與 Vue2.x 使用的 Options Api 有什麼不同?

来源:https://www.cnblogs.com/smileZAZ/p/18057289
-Advertisement-
Play Games

這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助 開始之前 Composition API 可以說是Vue3的最大特點,那麼為什麼要推出Composition Api,解決了什麼問題? 通常使用Vue2開發的項目,普遍會存在以下問題: 代碼的可讀性隨著組件變大而變差 每一種代碼復用的方式 ...


這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助

開始之前

Composition API 可以說是Vue3的最大特點,那麼為什麼要推出Composition Api,解決了什麼問題?

通常使用Vue2開發的項目,普遍會存在以下問題:

  • 代碼的可讀性隨著組件變大而變差
  • 每一種代碼復用的方式,都存在缺點
  • TypeScript支持有限

以上通過使用Composition Api都能迎刃而解

正文

一、Options Api

Options API,即大家常說的選項API,即以vue為尾碼的文件,通過定義methodscomputedwatchdata等屬性與方法,共同處理頁面邏輯

如下圖:

可以看到Options代碼編寫方式,如果是組件狀態,則寫在data屬性上,如果是方法,則寫在methods屬性上...

用組件的選項 (datacomputedmethodswatch) 組織邏輯在大多數情況下都有效

然而,當組件變得複雜,導致對應屬性的列表也會增長,這可能會導致組件難以閱讀和理解

二、Composition Api

在 Vue3 Composition API 中,組件根據邏輯功能來組織的,一個功能所定義的所有 API 會放在一起(更加的高內聚,低耦合)

即使項目很大,功能很多,我們都能快速的定位到這個功能所用到的所有 API

三、對比

下麵對Composition ApiOptions Api進行兩大方面的比較

  • 邏輯組織
  • 邏輯復用

邏輯組織

Options API

假設一個組件是一個大型組件,其內部有很多處理邏輯關註點(對應下圖不用顏色)

可以看到,這種碎片化使得理解和維護複雜組件變得困難

選項的分離掩蓋了潛在的邏輯問題。此外,在處理單個邏輯關註點時,我們必須不斷地“跳轉”相關代碼的選項塊

Compostion API

Compositon API正是解決上述問題,將某個邏輯關註點相關的代碼全都放在一個函數里,這樣當需要修改一個功能時,就不再需要在文件中跳來跳去

下麵舉個簡單例子,將處理count屬性相關的代碼放在同一個函數了

function useCount() {
    let count = ref(10);
    let double = computed(() => {
        return count.value * 2;
    });

    const handleConut = () => {
        count.value = count.value * 2;
    };

    console.log(count);

    return {
        count,
        double,
        handleConut,
    };
}

組件上中使用count

export default defineComponent({
    setup() {
        const { count, double, handleConut } = useCount();
        return {
            count,
            double,
            handleConut
        }
    },
});

再來一張圖進行對比,可以很直觀地感受到 Composition API在邏輯組織方面的優勢,以後修改一個屬性功能的時候,只需要跳到控制該屬性的方法中即可

邏輯復用

Vue2中,我們是用過mixin去復用相同的邏輯

下麵舉個例子,我們會另起一個mixin.js文件

export const MoveMixin = {
  data() {
    return {
      x: 0,
      y: 0,
    };
  },

  methods: {
    handleKeyup(e) {
      console.log(e.code);
      // 上下左右 x y
      switch (e.code) {
        case "ArrowUp":
          this.y--;
          break;
        case "ArrowDown":
          this.y++;
          break;
        case "ArrowLeft":
          this.x--;
          break;
        case "ArrowRight":
          this.x++;
          break;
      }
    },
  },

  mounted() {
    window.addEventListener("keyup", this.handleKeyup);
  },

  unmounted() {
    window.removeEventListener("keyup", this.handleKeyup);
  },
};

然後在組件中使用

<template>
  <div>
    Mouse position: x {{ x }} / y {{ y }}
  </div>
</template>
<script>
import mousePositionMixin from './mouse'
export default {
  mixins: [mousePositionMixin]
}
</script>

使用單個mixin似乎問題不大,但是當我們一個組件混入大量不同的 mixins 的時候

mixins: [mousePositionMixin, fooMixin, barMixin, otherMixin]

會存在兩個非常明顯的問題:

  • 命名衝突
  • 數據來源不清晰

現在通過Compositon API這種方式改寫上面的代碼

import { onMounted, onUnmounted, reactive } from "vue";
export function useMove() {
  const position = reactive({
    x: 0,
    y: 0,
  });

  const handleKeyup = (e) => {
    console.log(e.code);
    // 上下左右 x y
    switch (e.code) {
      case "ArrowUp":
        // y.value--;
        position.y--;
        break;
      case "ArrowDown":
        // y.value++;
        position.y++;
        break;
      case "ArrowLeft":
        // x.value--;
        position.x--;
        break;
      case "ArrowRight":
        // x.value++;
        position.x++;
        break;
    }
  };

  onMounted(() => {
    window.addEventListener("keyup", handleKeyup);
  });

  onUnmounted(() => {
    window.removeEventListener("keyup", handleKeyup);
  });

  return { position };
}

在組件中使用

<template>
  <div>
    Mouse position: x {{ x }} / y {{ y }}
  </div>
</template>

<script>
import { useMove } from "./useMove";
import { toRefs } from "vue";
export default {
  setup() {
    const { position } = useMove();
    const { x, y } = toRefs(position);
    return {
      x,
      y,
    };

  },
};
</script>

可以看到,整個數據來源清晰了,即使去編寫更多的 hook 函數,也不會出現命名衝突的問題

小結

  • 在邏輯組織和邏輯復用方面,Composition API是優於Options API
  • 因為Composition API幾乎是函數,會有更好的類型推斷。
  • Composition API對 tree-shaking 友好,代碼也更容易壓縮
  • Composition API中見不到this的使用,減少了this指向不明的情況
  • 如果是小型組件,可以繼續使用Options API,也是十分友好的

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • STM32ADC單通道轉換 1. 初始化 ADC功能初始化主要分三部分,GPIO初始化、ADC模式初始化與NVIC初始化。 1.1初始化GPIO void ADC_GPIO_Config(void) // 配置ADC通道引腳 { GPIO_InitTypeDef GPIO_InitStructure ...
  • 隨著大數據技術的演進和信息安全性需求的提升,數據規模的持續擴張為數據運維工作帶來了嚴峻考驗。面對海量數據所形成的繁重管理壓力,運維人員面臨效率瓶頸,而不斷攀升的人力成本也使得單純依賴擴充運維團隊來解決問題變得不再實際可行。 由此可見,智能化與高效便捷是運維發展的必然方向。袋鼠雲所推出的巡檢報告功能, ...
  • 前言: insert into t2 select * from t1; 這條語句會對查詢表 t1 加鎖嗎?不要輕易下結論。對GreatSQL的鎖進行研究之前,首先要確認一下事務的隔離級別,不同的事務隔離級別,鎖的表現是不一樣的。 實驗: 創建測試表t1,t2 greatsql> create ta ...
  • 金融業務產品授信準入、交易營銷等環節存在廣泛的風控訴求,隨著業務種類增多,傳統的專家規則、評分卡模型難以應付日趨複雜的風控場景。 在傳統風控以專家規則系統為主流應用的語境下,規則模型的入參習慣被稱為“變數”。基於專家規則的風險評估,存在規則觸發閾值難量化的特點,規則命中精準度提升存在瓶頸。 隨著機器 ...
  • 本文分享自華為雲社區《GaussDB資料庫SQL系列-動態語句》,作者:Gauss松鼠會小助手2。 一、前言 在資料庫中構建動態SQL語句是指根據不同的條件或參數創建不同的SQL語句。這通常是為了適應不同的業務需求,提高SQL的靈活性和效率。GaussDB資料庫是一款具備高性能、高可用性和高擴展性的 ...
  • 本文分享自華為雲社區《GaussDB跨雲容災:實現跨地域的資料庫高可用能力》,作者:GaussDB 資料庫。 金融、銀行業等對數據的安全有著較高的要求,同城容災建設方案,在絕大多數場景下可以保證業務數據的安全性,但是在極端情況下,如遇不可抗力因素等,要保證數據的安全性,就需要採取跨地域的容災方案。 ...
  • Ubuntu22.04安裝 本操作在虛擬機上 安裝Redis 1)更新系統 sudo apt update sudo apt upgrade 2)安裝Redis sudo apt install redis-server 3)測試Redis是否工作 redis-cli --version syste ...
  • Linux入門(五) 本篇文章主要講述下文件處理相關的命令 1: 顯示許可權 ls -lh 總用量 36K drwxrwxr-x 5 zh zh 4.0K 2月 28 16:47 app -rw-rw-r-- 1 zh zh 530 2月 22 18:25 build.gradle drwxrwxr- ...
一周排行
    -Advertisement-
    Play Games
  • 不廢話,直接代碼 private Stack<Action> actionStack = new Stack<Action>(); private void SetCellValues() { var worksheet = Globals.ThisAddIn.Application.ActiveS ...
  • OpenAPI 規範是用於描述 HTTP API 的標準。該標準允許開發人員定義 API 的形狀,這些 API 可以插入到客戶端生成器、伺服器生成器、測試工具、文檔等中。儘管該標準具有普遍性和普遍性,但 ASP.NET Core 在框架內預設不提供對 OpenAPI 的支持。 當前 ASP.NET ...
  • @DateTimeFormat 和 @JsonFormat 是 Spring 和 Jackson 中用於處理日期時間格式的註解,它們有不同的作用: @DateTimeFormat @DateTimeFormat 是 Spring 框架提供的註解,用於指定字元串如何轉換為日期時間類型,以及如何格式化日 ...
  • 一、背景說明 1.1 效果演示 用python開發的爬蟲採集軟體,可自動抓取抖音評論數據,並且含二級評論! 為什麼有了源碼還開發界面軟體呢?方便不懂編程代碼的小白用戶使用,無需安裝python、無需懂代碼,雙擊打開即用! 軟體界面截圖: 爬取結果截圖: 以上。 1.2 演示視頻 軟體運行演示視頻:見 ...
  • SpringBoot筆記 SpringBoot文檔 官網: https://spring.io/projects/spring-boot 學習文檔: https://docs.spring.io/spring-boot/docs/current/reference/html/ 線上API: http ...
  • 作為後端工程師,多數情況都是給別人提供介面,寫的好不好使你得重視起來。 最近我手頭一些活,需要和外部公司對接,我們需要提供一個介面文檔,這樣可以節省雙方時間、也可以防止後續扯皮。這是就要考驗我的介面是否規範化。 1. 介面名稱清晰、明確 顧名思義,介面是做什麼的,是否準確、清晰?讓使用這一眼就能知道 ...
  • 本文介紹基於Python語言,遍歷文件夾並從中找到文件名稱符合我們需求的多個.txt格式文本文件,並從上述每一個文本文件中,找到我們需要的指定數據,最後得到所有文本文件中我們需要的數據的合集的方法~ ...
  • Java JUC&多線程 基礎完整版 目錄Java JUC&多線程 基礎完整版1、 多線程的第一種啟動方式之繼承Thread類2、多線程的第二種啟動方式之實現Runnable介面3、多線程的第三種實現方式之實現Callable介面4、多線的常用成員方法5、線程的優先順序6、守護線程7、線程的讓出8、線 ...
  • 實時識別關鍵詞是一種能夠將搜索結果提升至新的高度的API介面。它可以幫助我們更有效地分析文本,並提取出關鍵詞,以便進行進一步的處理和分析。 該介面是挖數據平臺提供的,有三種模式:精確模式、全模式和搜索引擎模式。不同的模式在分詞的方式上有所不同,適用於不同的場景。 首先是精確模式。這種模式會儘量將句子 ...
  • 1 為啥要折騰搭建一個專屬圖床? 技術大佬寫博客都用 md 格式,要在多平臺發佈,圖片就得有外鏈 後續如博客遷移,國內博客網站如掘金,簡書,語雀等都做了防盜鏈,圖片無法遷移 2 為啥選擇CloudFlare R2 跳轉:https://dash.cloudflare.com/ 有白嫖額度 免費 CD ...