[JSDC2019] 我有一堆選擇 Vue 開發框架的理由

Transcript

1. 我有⼀一堆選擇 Vue 框架的理理由 Kuro Hsu @ JSDC2019

2. Kuro Hsu - Organizers of Vue.js Taiwan - https://kuro.tw -

   kurotanshi@gmail.com - @kurotanshi

3. vue.tw 社群現況

4. None
5. None

6. 今年年⾄至今成長近兩兩千⼈人次

7. • https://vue.tw • 每個⽉月⼀一次的實體聚會 (⽬目前主要在台北) • 活動票券幾乎在⼀一分鐘內秒殺 • 每場報到率 85%

   以上 • 社團討論氣氛融洽 (?)

8. 如何選擇⼯工具

9. None
10. None

11. 如果你是新⼿手 • 看現在哪個 夯 / 潮 / 猛 / ⾼高⼤大上

    就⽤用什什麼 • 看公司要我⽤用什什麼我就⽤用什什麼 • 因為我只會什什麼就⽤用什什麼 • 因為我剛學會什什麼就想⽤用什什麼

12. ⼿手上拿著錘⼦子的⼈人 看什什麼都像釘⼦子

13. 如果你是決策者 • 為了了解決現有的問題 • 降低完成任務的成本 • 排除未來來可能的遇到的問題

14. None

15. 為什什麼要⽤用 Vue.js？

16. 現在好好的 管他過去幹嘛

17. 就是因為有痛到才要換

18. 不然你也可以繼續⽤用 jQuery 啊 不瞞您說我也還在⽤用

19. 「我」為什什麼選擇 Vue.js 開發

20. 曾經我也是個冒險者 
 (2013)

21. (2015)
 
 ……

22. 新技術的考量量 (當時) • React ？ • JSX 沒⼈人懂 • 存在感太薄弱我忘了了為什什麼沒選它了了

    • Angular 2 ？ • RC ⼀一時爽，⼀一直 RC ... • 沒學 TypeScript

23. 遇⾒見見 Vue.js 之後

24. 新技術的考量量 (當時) • Vue.js • Syntax 與 ng1 有 87%

    像，轉換成本低 • 夠輕量量、好上⼿手 • 正好⾜足夠負擔當時專案的複雜度 • 試 run 幾個⼩小專案之後就決定是它了了

25. Vue.js 快速簡介

26. Vue.js • 儘可能簡單的 API • 響應式的資料綁定 • 可組合式的視圖元件 • 只專注在視圖層

    • 可以跟其他 library 整合

27. Library or Framework ?

28. None

29. 「The Progressive JavaScript Framework」 Vue core Vue-router Vuex Vue-Cli Nuxt.js

30. 指令式渲染 • 如 jQuery，以操作 DOM Node 為基礎的開 發模式 • 開發⽅方式直覺，透過

    Selector 取得 DOM 就 開始操作 • 優點就是爽，但程式架構擴⼤大複雜後，程式 碼混雜不易易維護

31. 宣告式渲染 • 以操作物件模型為基礎的開發模式。 • ⾏行行為關注點放在資料 ( Model ) 與狀狀態 •

    直接描述 狀狀態 與 DOM 的映射關係，⽽而不 是直接操作 DOM • view = render(state) 
 state 輸入， DOM 輸出。
32. None
33. None

34. Vue Component

35. Component System UI 結構 組件樹

36. None
37. None
38. None
39. None

40. 如何導入 Vue.js

41. 直接引入 vue.js

42. Vue-Cli 建立專案 $ npm install @vue/cli -g $ yarn global

    add @vue/cli $ vue create 專案名稱

43. Vue-Cli 建立專案

44. None

45. Vue-loader

46. HTML Script Style

47. None
48. None

49. SPA or MPA

50. Vue-Router

51. Vue-Router

52. Multiple page vue.config.js

53. 打包

54. 打包 ⽣生成的檔案在 dist ⽬目錄下

55. 專案開發週期 建立模板 初始化 開發 上線 靜態 HTML
 CSS Vue Template

    vue-cli Project initialize Mock Data Testing webpack dev server / proxy 打包 /
 建立 HTML 上傳 CDN 程式發布

56. Next - Vue 3.0

57. None

58. • 更更⼩小、更更快 • 加強對 TypeScript 的⽀支援 • 加強 API 設計⼀一致性

    • 提⾼高可維護性 • 開放更更多底層功能

59. • Object.defineProperty -> Proxy API • Virtual DOM 重構 •

    增強編譯時的優化

60. ! Composition Functions • 之前叫 function-based API • 以「組合代替繼承」來來實作元件功能的複⽤用 •

    對 TypeScript 類型推導的⽀支援更更好 • Tree-shaking friendly、編譯後程式碼更更容易易被壓縮

61. 對比過去做法

62. Mixins

63. Mixins 可能造成 Namespace 的衝突 從 Mixins 引入的 options 難以追蹤來來源

64. HOC: Higher-order Components

65. Props 來來源不清晰 Props namespace 衝突問題 多餘的元件實體造成性能浪費 HOC: Higher-order Components

66. Renderless Components

67. Renderless Components options 來來源清晰 無 namespace 衝突問題 多餘的元件實體造成性能浪費

68. Composition Functions API

69. options 來來源清晰 無 namespace 衝突問題 沒有多餘的元件實體浪費 Composition Functions API

70. Composition Functions Converter https://suspicious-mclean-0e54c3.netlify.com/

71. 與 React Hooks 對比 • 我知道⼀一定有⼈人會問所以我現在先講 • 兩兩者同樣為了了處理理邏輯組合與複⽤用問題 • Vue

    setup( ) 只會在 init 被呼叫⼀一次 • 沒有 State Hooks 的閉包陷阱 • 沒有內聯聯函式 callback 導致⼦子組件不斷被觸發更更新問題
72. None

73. 在社群 激戰 討論後， 更更新後的 RFC 已取消此策略略 請參參考: https://github.com/vuejs/rfcs/commit/6fe6f7be06dd5982be3c57e248fcd66cd55748e0

74. • 已知 2.x -> 3.x 不會有 Breaking Change，完全相容現有 API •

    加強對 TypeScript ⽀支援 !== 只能⽤用 TypeScript • 更更多的是針對底層的改寫，對多數開發者來來說沒有明顯差距 • ⽬目前仍在 RFC 階段

75. No Breaking Changes! No Breaking Changes! No Breaking Changes!

76. ⚠ 投資⼀一定有風險，嚐鮮前應詳閱公開說明書 ⚠

77. 結語

78. 如何選擇⼯工具 現在學這個是不是過時了了 我該等到最強的那個出現再開始學嗎

79. None

80. • 有效解決問題才是重點 • 框架、⼯工具都是因應問題⽽而⽣生，在不考慮場景的 情況下尋找解法就像是盲⼈人摸象 • ⼯工具的實作⽅方式不同，但理理念念卻很多類似 • 保持開放技術的多樣性是有益的，今天學的東⻄西 會成為明天的養分

    • 優良的部分仍會保留留在其他地⽅方被實現

81. Thanks