其实去年就想这一系列，但是就怕写完变成别人的线上课程，所以没有写 (想太多了)
想了一年之後，还是觉得不要留什麽招在自己的内心，这样才是对自己有信心的表现
因为工程师的价值并不是做了什麽，而是为什麽这麽做，对吧！

从需求、观念到功能

在学习 Vue.js 的路上，我从语法开始学习，从传递、更新资料的方式，也有拿来做过去 jQuery 常做的抽换 class。

但是初学一开始，比起用 jQuery 很难从头写一个页面，不知道存在 data 中的值如何使用，只是跟着官网的范例写了一个 count++

Object-oriented programming

过往写过一阵子的 C++，所以对於 OO 有着一种执着，但是自从写了 JS 之後就不再这样了。
对於 OO 还是有着一定的观念。

封装 + 继承 + 动态连结 = 物件导向

这也是 JS 很不 OO 的由来，不过後来 JS 有导入 private variable 了，所以，应该也算是补齐了最後一块拼图了。

Private class features - JavaScript | MDN

这些观念用在 Vue 上依然非常好用。

functional programming

在学习 Vue 的过程，也有学习一些 React，所以会跟 React 的框架学习一些观念。
只是认识这些观念的过程，总是会遇到一些「λ狂热信徒」，不过也是因为这些信徒的热情介绍，让我认识许多关键字，有助於我对 Vue 框架使用。

• immutable: 资料不更新，只有替换资料
• pure function: function 的输出只跟输入有关
• higher order function: function 当参数传递进来 HOF，会产生新的 function
• currying: 可以执行到一半的 function

这些是我用在 Vue 上面的 functional programming，也许还有其它的...

达到 MVVM 效果的自动化魔法 computed 和 watch

当需求里面有资料同步连动并更新画面时，第一个反应就是这两个选一个上场！方便又有效！
但真的是这样吗？

Computed Properties and Watchers — Vue.js

学习 Vue 的过程，第一个关卡就就是要认识 computed 和 watch 这两个新东西，总是让人混乱不已，总觉得 watch 就是 computed + data ，不知道要选哪一个比较适合当下面对的问题。

watch API — Vue.js

对 watch 的更新，如果物件太深，就会失效，也不知道多深才会出问题，但总是用 deep: true 似乎也不是办法？

切分 component 切太多记不住？！

不知道什麽样的需求，要切分 component，还是画面太复杂时，就切一下。
究竟是要怎麽切才是合理的，component 的 component 太深怎麽每一次都会吃掉我大部份的认知负担，是不是 component 不可以太深？还是有其它的问题？

表单绑定神器: 魔法 attribute v-model 但省了什麽 code

需求提到表单填写时，就会想用 v-model，似乎是表单麻烦事的必备良方。

Form Input Bindings — Vue.js

v-model 似乎可以让 template (html) 的写法变得简洁，但是 v-model 加上 computed 的时候，会让 get/set 的写法一直反覆出现，却又不能合并，好像也是无法改变的事情。

Two-way Computed Property, Form Handling | Vuex

在 vuex 中有提到使用了 v-model 和 computed 的做法，可以让画面直接绑到 state，但这样写会让 code 变多！阅读失去了魔法的 v-mode 就觉得很多赘 code！

失控 component 与暴量的 attribute, event

需求的画面很复杂时，就是要切分 component，但是每个 component 之间的沟通就是让人头大，每次有 bug 时就不知道在哪一层出现问题，用了 Vue 好像和用 jQuery 没什麽差别只是换了一个工具，开发的麻烦性也没有变少。

v-bind Shorthand, Template Syntax — Vue.js
Props — Vue.js

v-on Shorthand, Template Syntax — Vue.js
Custom Events — Vue.js

有了 component ，进入了一个可以自己定义 html 的标签的梦幻自由国度，什麽都可以抽出来，又什麽都可以传出来。

Custom Events — Vue.js
.sync Modifier, Custom Events — Vue.js

必要时每个 prop 都可以双向绑定成 v-model, prop.sync(v2), v-model:prop(v3) 这样做用起来很清爽，不用看见成对的 prop/event。
但是当我的 component 有二十个栏位难道我要一个一个绑吗？(累！)
不可以传入之後，直接在 component 里面修改值就好了吗？一定要传出来？

顿时间让自己无所适从，每次写 vue 要切 component 都不知道要怎麽做 prop/event 才会真正让自己觉得省下一些工夫，而不是每一次都在做苦工。

我的 component 不是我的 component

用 Vue 更换画面等同於更换 component 只是这个 component 的画面比较大。那要用哪个技术抽换呢？这个有一定吗？还是不管是什麽，通通用 vue route 就对了？是吗？

Conditional Rendering — Vue.js
keep-alive with Dynamic Components, Dynamic & Async Components — Vue.js
Getting Started | Vue Router

在 vue 中换 component 有几种方式

1. 用 v-if 和变数
2. 用 <component :is=""> 和变数
3. 用 <router-view> 和 router

这几种方式和需求之间的距离有多远？
好像选哪一种都没差 component 都会抽换

vue-router

等到拿来做专案时，就配合不同的需求、画面，试着分类 component 并且透过 axios 取得资料，从这开始就出现了一些混乱的情况，API 呼叫混乱，axios 引入的位置也没有一定的规则

API 收到 403 时，要怎麽优雅的请画面跳转到登入页

vuex

使用 vuex 管资料，一开始就觉得只是将 data 移到 state 而已。mutate 和 getters 似乎也没有什麽特别的用途，若资料没有要改变，似乎也不用特别写。

逻辑写在 aciton 和 mutation 好像也没有什麽差别。也许只要写 action 和 state 就好。

以上，如果你已经写了一段时间的 vue ，而且有任何一个一样的想法，请一定要追这一个连载，以上这些觉得没有差别的想法，就会造成一些 random coding 的产出

从需求判断资料读写需求

从现代前端工程师该如何聆听需求，请务必在需求访谈时，特别注意「资料读写」的情境。这些情境就是我们要处理的条件判断。
「资料读写」这个角度去探讨，画面元件设计与资料编辑权限的相关性，配合其它程序设计的理论，建构出一个前端框架使用的思考流程。

如果你有上述的困难，请订阅这一系列。这一系列会 (希望可以) 带着你的思绪思考，运用技术的过程，如何写出好维护、自我文件化、缩小 bug 范围、好追纵错误的程序码 (希望看完的人不会觉得我在胡说八道。哈哈)。