精讀《Nuxtjs》

1 引言

Nuxt 是基於 Vue 的前端開發框架，此次咱們經過 Introduction toNuxtJS 視頻瞭解框架特點以及前端開發框架的基本要素。

nuxt 與 next 結構很像，能夠結合在一塊兒看

視頻介紹了 NuxtJs 的安裝、目錄結構、頁面路由、導航模版、asyncData、meta、vueX。

這是一個入門級視頻，因此上面所列舉的特徵都是一個前端開發框架的最核心的基本要素。一個前端開發框架，安裝、目錄結構、頁面路由、導航模版必定是最要下功夫認真設計的。

asyncData 和 Vuex 都在解決數據問題，meta 則是經過約定語法控制網頁 meta 屬性，這部分值得與 React 體系作對比，在精讀部分再展開。

Nuxtjs 前端開發框架不只提供了腳手架的基本功能，還對項目結構、代碼作了約定，以減小代碼量。從這點能夠看出，腳手架永遠圍繞兩個核心目標：讓每一行源碼都在描述業務邏輯；讓每一個項目結構都相同且易讀。

20 年前，幾百行 HTML、Css、Js 代碼就能完成一個完整的項目，只須要遵照 W3C 的基本規範就足夠了，每個項目代碼都簡單清晰，並且因爲沒有複雜的業務邏輯，致使代碼結構也很是簡單。但如今前端項目複雜度逐漸升高，一個大型項目源碼數量可能達到幾十萬行、幾百萬行，這是 W3C 規範沒有設想到的，所以出現了各類工程化與模塊化方案解決這個複雜度問題，也引起了各個框架間約定的割裂，且設計合理程度各不相同。

Nuxtjs 等框架要作的就是定義支持現代大型項目的前端研發標準，這個規範具備網絡效應，即用的人越多，價值越大。

接下來咱們進入正題，看看 Nuxt 腳手架定義了怎樣的開發規範。

2 概述

安裝

使用 npx create-nuxt-app app-name 建立新項目。這個命令與 create-react-app 同樣，區別主要是模版以及配置不一樣。

這個命令本質上是拉取一個模版到本地，並安裝 nuxt 系列腳本做爲項目依賴，並自動生成一系列 npmScripts：

{
  "scripts": {
    "dev": "nuxt",
    "build": "nuxt build",
    "start": "nuxt start",
    "generate": "nuxt generate",
    "lint": "eslint --ext .js,.vue --ignore-path .gitignore .",
    "test": "jest"
  },
  "dependencies": {
    "nuxt": "^2.0.0"
  }
}
複製代碼

以後便可經過 npm start 等命令開發項目，對大部分項目來講，npmScripts 啓動是最能達成共識的。

這種安裝方式另外一個好處是，依賴都被安裝在了本地，即開發環境 100% 內置在項目中。Nuxt 沒有采用全局 cli 命令方式執行，第一是 npmScripts 更符合你們通用習慣，不須要記住不一樣腳手架繁瑣的名稱與不一樣約定的啓動命令，第二是全局腳手架一旦進行不兼容升級，老項目就面臨維護難題。

目錄結構

├── .nuxt
├── layouts
├── pages
├── store
├── assets
├── static
├── middleware
├── plugins
├── nuxt.config.js
複製代碼

pages

頁面文件存放的目錄，路徑 + 文件名即路由名，關於更多約定路由的信息，在下一節頁面路由詳細說明。

layouts

模版文件存放的目錄，文件名即模版名，頁面能夠經過定義模版在選擇使用的模版。

store

全局數據流目錄，在 vueX 章節介紹。

assets、static

分別存放不需被編譯的資源文件與非 .vue 的靜態文件，好比 scss 文件。

因爲 .vue 文件集成了 html、js、css，所以通常不會再額外定義樣式文件在 static 文件夾中。

固然，這是 Vue 生態的特別之處，在 React 生態中會存在大量 .scss 文件混雜在各個目錄中，比較影響閱讀。

middleware、plugins

中間件與插件，這兩個目錄是可選的，做爲一種定製化拓展能力。

.nuxt

爲實現約定路由等便捷功能，啓動項目時須要自動生成一些文件做爲真正項目入口，這些文件就存儲在 .nuxt 目錄下，gitingore 且無需手動修改。

nuxt.config.js

nuxt 使用 js 文件做爲配置文件，比 json 配置文件拓展性更好一些，這個文件也是整個項目惟一的配置文件。

基本上 pages、layouts、store、assets、以及惟一的配置文件基本成爲現代前端開發框架的標配。

頁面路由

nuxt 支持約定路由：

├── pages
│   ├── home.vue
│   └── index.vue
複製代碼

上述目錄結構描述了兩個路由：/ 與 /home。

也支持參數路由，只要如下劃線做爲前綴命名文件，就定義了一個動態參數路由：

├── pages
│   ├── videos
│   │   └── _id.vue
複製代碼

/videos/* 都會指向這個文件，且能夠經過 $route.params.id 拿到這個 url 參數。

另外一個特性是嵌套路由：

├── pages
│   ├── videos
│   │   └── index.vue
│   └── videos.vue
複製代碼

videos.vue 與 videos/index.vue 都指向 /videos 這個路由，若是這兩個文件同時存在，那麼外層的 videos 就會做爲外層攔截全部 /videos 文件夾下的路由，能夠經過 nuxt-child 透出子元素：

# pages/videos.vue
<template>
  <div>
    videos
    <nuxt-child />
  </div>
</template>
複製代碼

導航模版

頁面公共邏輯，好比導航條能夠放在模版裏，模版的目錄在 layouts 文件夾下。

默認 layouts/default.vue 對全部頁面生效，但也能夠建立例如 layouts/videos.vue 特殊導航文件，在 pages/ 頁面文件經過以下申明指定使用這個模版：

<script> export default { layout: "videos" }; </script>
複製代碼

asyncData

asyncData 是 nuxt 支持的異步取數函數，能夠替代 data。

data 函數：

<script> export default { data() { return {}; } }; </script>
複製代碼

對於異步場景，能夠用 asyncData 替代：

<script> export default { async asyncData() { return await fetch("/"); } }; </script>
複製代碼

meta

nuxt 容許在 .vue 頁面文件自定義 head 標籤信息：

<script> export default { headr() { return { title: "", meta: { charset: "utf-8" } }; } }; </script>
複製代碼

這是開發框架提供的特性，不過在 React 體系下能夠經過 useTitle 等自定義 Hooks 解決此問題，將框架功能降維到代碼功能，會更容易理解些。

vueX

nuxt 集成了 vuex，在 store/ 文件夾下建立數據模型：

export const state = () => ({
  videos: [],
  currentVideo: {}
})

export const mutations = {
  SET_VIDEOS (state, videos) {
    state.videos = videos
  }
  SET_CURRENT_VIDEO (state, video) {
    state.currentVideo = video
  }
}
複製代碼

接下來就能在 pages 文件夾下的頁面組件使用了：

<script> import { mapState } from "vuex"; export default { async fetch({ $axios, params, store }) { const reponse = await $axios.get(`/videos/${params.id}`); const video = response.data.data.arrtibutes; store.commit("SET_CURRENT_VIDEO", video); } }; </script>
複製代碼

將 return 替換爲 store.commit 便可，更多語法能夠參考 vuex 文檔。

3 精讀

Nuxtjs 框架作了幾件事情：

1. 統一執行命令。
2. 統一開發框架。
3. 統一目錄與代碼規範。
4. 內置公共 utils 函數。

統一執行命令

命令行是全部開發者天天都要用上十幾回甚至幾十次的場景，試想一下團隊中項目分別有以下這麼多不一樣的啓動命令會怎麼樣？

1. npm start.
2. monkey dev.
3. npm run ng.
4. npm run bootstrap & banana start.
5. ...

我永遠不知道下一個項目該如何啓動，這大大下降了開發效率。更嚴重的是，有的項目能夠經過 npm run docs 查看文檔，有的項目不能；有的項目 npm run build 能夠觸發編譯，有的項目卻無需編譯，等等，所謂的環境不一致或者說遷移成本，學習成本，都是由最開始負責搭建項目腳手架的同窗對架構設計不一致致使的，然而沒有必須用 monkey dev 才能運行起來的項目，但項目卻可能由於被設計爲 monkey dev 啓動而顯得與其餘項目格格不入，甚至難以統一維護。

Nuxtjs 等前端開發框架統一執行命令就是爲了解決這個問題，統一開發者習慣須要很長的時間週期，但這個趨勢不可擋。

統一開發框架

雖然如今 React、Vue、Angular 框架各有利弊，但若是一個團隊的項目同時使用了兩個以上的框架，沒有人會以爲這是一件好事。

誠然每一個框架都有本身的特色，在不一樣維度都一些優點，但三大框架能並存，說明各自都沒有絕對的殺手鐗來消滅對方。

對開源來講，多元化是活力的源動力，但對一家公司來講，多元化就是一場災難，至今沒有一個框架敢說本身的優點是 「與其餘框架混合使用能夠提高總體開發效率」。

前端開發框架要解決的最重要問題也是這一點，不管如何只能選擇一種開發框架，Nuxtjs 選擇了 Vue，Nextjs 選擇了 React。

統一目錄與代碼規範

目錄和代碼規範不會從根本上影響項目的通用性，由於不一樣的目錄結構能夠經過映射來兼容，不一樣的代碼規範不會影響代碼執行。因此目錄與代碼規範真正影響的是一個程序員對項目的 「解碼成本」。

所謂解碼成本，就是程序員理解項目邏輯所須要的成本。若是你是一個銷售主管，讓團隊週報統一用一種格式彙總絕對比 「用本身喜歡的方式彙總」 效率高，而對編程也同樣，一個徹底不一樣的目錄結構和代碼規範對程序員來講是巨大的閱讀阻礙，甚至可能引起噁心反應。

因此不一樣的目錄結構和代碼規範是沒有必要的壁壘，除非你的團隊已經對某種規範產生達成了牢固的共識，不然最好和其餘團隊共享相同的目錄結構與代碼規範。改變代碼規範是一件很可貴事情，但只要不一樣規範的團隊間產生了長期合做關係，規範統一就勢必會被提上議程，那麼爲什麼不能在公司層面早一點達成共識，提早消除這種痛苦呢？

因此統一目錄與代碼規範是前端開發框架須要優先肯定的，不少時候不要去質疑爲何目錄叫 layouts 而不叫 layout，由於這個規範背後造成的協同網絡規模越大，叫什麼名字就越不重要。

內置公共 utils 函數

讓業務開發更聚焦，還能夠經過抽取通用的邏輯的方式解決，但須要解決兩個問題：

1. 雖然將公共函數抽成 npm 包能夠解決代碼複用問題，但關鍵是怎麼保證你的代碼能被別人複用？
2. 如何讓業務通用的 utils 代碼有效沉澱並從項目中移除？

腳手架內置公共 utils 函數就爲了解決這個問題。上面幾個小節解決了通用命令、框架、規範，但實際代碼中，router history fetch store 等等概念也都是能夠統一的，沒有一個項目必須用定製的 fetch 函數才能取數，但一開始就定製了 fetch 會致使耦合了不可預期的、沒有必要的業務邏輯，成爲理解與提效的阻礙。

因此統一這些能統一的包，是進一步提效的關鍵。也許有人會以爲斷了本身造輪子的路，但就像咱們現在都不會重寫瀏覽器內核邏輯同樣，穩定的邏輯不只帶來了全行業的提效，還催生了前端崗位帶來大量的就業，一樣的，統一底層通用函數，實際上是斷了無心義產出這條路，每一個人都有追求更高價值事情的權利，不要把本身困在反覆造 fetch 函數這個低水平的活裏。

4 總結

若是一個項目沒有使用相似 Nuxtjs 開發框架，它面臨的不只僅是技術選型不統一的問題，長此以往這種項目勢必成爲 代碼孤島，當塵封在代碼倉庫幾年後，一系列文檔工具連接都失效後，就成爲誰也不想碰，不敢碰的高危代碼。

因此咱們今天不只要看到 Nuxtjs 提供的能力對項目開發有多麼便捷，更要看到這類框架帶來的協同效應有多麼巨大，若是它不能成爲整個前端的標準，至少要成爲大家公司，或者大家團隊的標準。

討論地址是：精讀《Nuxtjs》 · Issue #213 · dt-fe/weekly

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）