GitHub 地址：https://github.com/dom-bro/task-manager
接上篇：01 挑戰十分鐘創建一個新的全堆疊專案
想要專案快速迭代，輪子必不可少，normalize.css，element-plus，axios，moment，vue-router，less，前端必知必會的輪子你都知道嗎？
瀏覽器默認樣式統一 normalize.css
npm i normalize.css
只需在 src/main.js 中加一行即可
import 'normalize.css'
這個庫主要做的事是統一瀏覽器默認樣式，而非清除瀏覽器默認樣式，所以像 h1，h2，strong 這種自帶樣式的標簽仍然保留著樣式，body 的 margin 統一成了 0
UI 框架 element-plus
npm i element-plus
由于是全堆疊開發，產品 -> UI -> 前端 -> 后端 -> 資料庫，寫代碼我還行，ps 和 skecth 實在是力不從心啊，搞一個 UI 框架是必要的，
關鍵代碼
import 'element-plus/dist/index.css'
import ElementPlus from 'element-plus'
app.use(ElementPlus)
由于是要在整個專案中用，并且 element-plus 提供的大多陣列件都要被用到，這里就直接簡單粗暴的完整引入，
當然在具體的專案中也可以根據實際情況按需引入
網路請求 axios
npm i axios
import axios from 'axios'
window.axios = axios
我身為一個前段開發師，定義幾個全域變數很合理吧
日期處理 moment
npm i moment
import moment from 'moment'
window.moment = moment
正如我剛才所說，moment 每個頁面到處都在用，定義成全域變數也很合邏輯
SPA 路由 vue-router
npm i vue-router
vue 的官方路由，不需要解釋，
import { createRouter, createWebHistory } from 'vue-router'
const router = createRouter({
history: createWebHistory(),
routes: [],
})
app.use(router)
在添加了前端路由之后才真正算是正式開工了
接下來就可以一個頁面一個頁面地穩步前進啦
css 前處理器 less
npm i less
在 vue 的 sfc 里就可以用 less 啦
<style lang="less"></style>
最后
把 vite 腳手架生成的一些 hello world 示例代碼清理一下
新建一個首頁路由
{
path: '/',
component: () => import('./pages/Home.vue')
},
上圖右半拉是不可不知的 vue 開發除錯神器 vue-devtools，官方出品，必屬精品，
現在專案的主要依賴如下
# 前端
vite 3
vue 3
vue-router 4
element-plus 2
# 服務端
koa 2
koa-router 12
# 環境
node v16.15.0
npm v8.5.5
正文結束，點擊查看代碼變更
閑言碎語
element-plus or ant-design-vue ?
element-plus 是 element-ui 專門針對 vue3 出的版本，element-ui 和 ant-design-vue 都是極其優秀的框架，這倆框架我都有兩年左右的實戰專案經驗，兩者內含的常用組件不能說是雷同，簡直是一摸一樣，作為 ui 框架，主要的差異還是 ui 層面的，
選擇 element-ui 也是因為先入為主，要知道在 2018 年啟動這個專案時我甚至都沒聽說過 ant-design-vue
less or sass ?
其實我從事前端的前幾年主要是在用 sass 的，官網號稱其是世界上最成熟、穩定和強大的 css 擴展語言，實至名歸，支持的特性確實多，但安裝起來咋就那么曲折呢，那個 node-sass 真是安一次，畝訓一次，
后來接觸了 less，雖然沒 sass 功能強大，但常用的變數，嵌套，mixin，函式等特性足夠用了啊，而且如此輕便，果斷棄 sass，全面轉向 less，
axios or fetch ?
兩者的特性差異我倒是沒研究過，不過我知道 fetch api 在瀏覽器環境有，在 node 環境卻沒有，為了獲得一致的開發體驗，強迫癥的我還是選擇 axios
vue-router 的 history 模式 or hash 模式 ？
一句話，我選 history 模式純粹是為了 url 美觀，
hash 模式利用 window 的 hashchange 事件監聽 url hash 部分的變化，從而匹配到對應的路由視圖，url 的 hash 部分是不會發送到服務器的，所以這種模式完全由前端維護，服務器無需任何處理，缺點就是對 SEO 不友好，url 也比較丑陋，
history 模式充分利用了 history.pushState API 在實作 URL 跳轉的同時不重新加載頁面，這種模式下 url 就是正常的 url，但是這種正常的 url 在加載頁面時走服務器請求，所以如果服務器不配置的話會出現 404，要解決這個問題需要在服務器添加一個簡單的回退路由，在 URL 不匹配任何靜態資源的情況下，回傳 index.html，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/502336.html
標籤：其他