以前幫公司協助面試過新人,早期我們在職缺條件上沒有特別列出需要有什麼前端框架的經驗,所以曾經有遇過背景是 react的受試者問說,為什麼我們是選擇框架的時候是 vue而不是 react,當時我就已經能夠很清楚得回答這個問題了,不過最近我對 react的了解有更加深入了之後,我對這有了一些新的想法…
11 posts tagged with "vue"
View All TagsVue Recursive Component
當 Component遞迴呼叫自己時 - 也就是使用 slot
並將同樣的 Component放進去的時候,如果沒有針對這種情形調整寫法就會報錯:
did you register the component correctly? For recursive components, make sure to provide the “name” option
這樣寫法稱之為 Recursive Component,在我研究之後分為以下兩種形態:
- 父子Component是同樣的Component
- 某Component的父子Component相同
Vue2 的 Vuex使用 Typescript寫法
前言
Vuex v4.0版本以上大幅改善了對 Typescript的支援、以及對 composition-api的整合,但是 Vuex v4.x版只支援 Vue3以上版本。
也就是說如果開發環境是 Vue v2.x版本的話,Vuex也就只能使用 v3.x版本。雖然說 Vuex v3.x版對於 Typescript的支援上也些限制和不順手,但只要做好註記 (annotation)的工作,基本上我覺得型別推導上還算蠻完整的,唯獨 Component中要引入 Vuex的時候就會有些限制,只有 state
可以型別推導,其餘 mutation
/action
等都會是 any
型別。不過對我個人來說有 state
型別推導就已經是相當實用,其他的就還是我可以忍受的範圍了。
Vue2的 Option-Based Component中使用Typescript的簡易方式
前言
之前使用 Vue2.x開發時又想使用 Typescript,當時遇到的困擾是… Component使用 Typescript時根本就吃不到 this的型別,所以基本上是無法直接使用的,唯一的方式也只能採用官方推薦的 Class Component寫法,會寫到覺得很生氣(?), Class Component的寫法實在是頗不直觀。
一直到 Vue3.0推出之後,才終於徹底改善了對 Typescript的支援;但我的工作上基於某些理由,短時間內無法轉為使用 Vue3.0,所以我就來簡單研究了一下,在 Vue2.x環境下是否有使用 Typescript合適方式?
相容 Vue2及 Vue3環境的 Component寫法
前言
理論上 Vue3.x大多數的寫法是有向下相容 Vue2.x的寫法,所以理論上.vue
檔Component的寫法只要同時符合 Vue3.x和 Vue2.x的寫法,是能夠將同一個檔案共用於兩者不同環境當中。
以下會針對幾種我遇過在這兩個環境中較大差異的部份以及解決方式做個說明。
Vue父子組件資料流設計 (1) 單向傳遞
落落長的前言
雖然說Vue上手容易,就以我來說我剛開始學習的時候幾乎是網路上看了幾篇文章就開始寫了,但是後來就吃了很多悶虧,慢慢在各專案中累積實戰經驗之後才知道有更好的做法,並且每種做法的差異以及適用的情境…
關於組件(Component)的設計當中,資料傳遞的設計幾乎是整個Vue的程式開發中最重要的一件事情…(個人見解 XD),尤其是當團隊(或者專案中)開始考量組件的複用性、開始重視組件的開發,這件事情尤其重要。
Vue父子組件資料流設計 (2) 雙向綁定–通用組件
一、單向/雙向資料流之差異及適用場景
前一篇文章「單向傳遞」中我有提到過,我自己「體感」自製的Component大約只有百分之20是使用單向資料流傳遞的。不過在Vue中的「雙向綁定」是一大特色(雖然當初也是 抄襲 參考Angular的),當中的變化以及學問可多了。
就我自己個人的經驗,剛開始學Vue時開發自製Component大多都是使用單向綁定,對於自製的雙向綁定的用法有些困惑,隨著經驗的累積才開始慢慢掌握技巧以及合適的用法。依照我自己個人的經驗,我會把這百分之20中所適用的情境分為兩種:
- 包裝resuse(可複用)的基本元素
- 因程式管理需求需抽離出來的大區塊
Vue父子組件資料流設計 (3) 雙向綁定–大組件
一、範例說明
本文是系列文當中討論「雙向綁定」的第二篇文章,在前一篇文章「Vue父子組件資料流設計 (2) 雙向綁定–通用組件」當中有介紹了兩種(我自己的經驗法則分類)會使用雙向綁定的組件類型:
- 通用組件
- 大組件
(譯)Vue.js App 效能優化: part1 – 效能優化和lazy loading
譯者說明
最近使用Vue.js投入公司產品開發花了不少心血,關於前端的效能是一件很重要的事情,這個系列文有做了一些有趣的探討,原文作者似乎也還沒寫完,我先從第一篇開始翻起,原文在此:
當行動優先導向成為標準、並且不確定性的網路環境也成為我們必須考慮的因素時,讓應用程式保持高速成為越來越困難的事情。在這個系列當中我會挖掘更深的Vue優化技術 – 我們在Vue Storefront當中所使用的技術,而你也可以用在你的Vue.js應用程式當中來讓他們瞬間讀取並且表現得平滑。我的目的是在這系列中對於Vue.js應用程式效能給出一個完整的指南。
- Part 1 – 介紹效能優化及lazy loading
- Part 2 – Lazy loading路由及第三方庫的反向模式(anti-pattern)
- Part 3 – Lazy loading Vuex模組
- Part 4 – Lazy loading單一Component
- Part 5 – Lazy loading函式庫和尋找最小集合
- Part 6 – 使用Service Worker cache
- Part 7 – 預讀取
(譯)Vue.js App效能優化: part2 – Lazy loading路由及第三方庫打包反向模式(anti-pattern)
在前一篇文章當中我們學到了什麼是切割程式碼、它是如何運作的以及在Vue.js應用程式中如何和lazy loading一起使用。現在我們將稍微深入一點的來看程式碼,並學習在Vue.js應用程式中最實用的程式碼切割的模式。