Vue.js作者尤雨溪談VueJS!

如何建立Vue.js
第一次提交Vue.js是在2013年末，當時我還在Google創新實驗室工作，那時它完全是一個隨機的實驗，我當時正在研究很多快速的UI原型，其中使用了Angular，只是感覺太麻煩，引入了許多實際上並不需要的東西，但也有一些我真正喜歡的東西，比如資料繫結，更新狀態的方式，你不必擔心強制直接操作DOM了，因此，想提取這些有價值的部分。

當我閱讀其他人的程式碼，或者我檢視新的即將推出的框架時，我會看到那些好的想法或良好的編碼最佳實踐，我可能沒有機會將它們應用到我的實際日常工作中，但我可以嘗試將它們應用到Vue中。

Vue.js2.0是另一個完全重寫並引入了一堆新功能，我們現在使用虛擬DOM，我們支援伺服器端渲染SSR，甚至是原生渲染。

在2016年初，中國開發者社群有一篇文章討論什麼框架將贏2016年或17年？有個傢伙發帖預測Vue會！

關於Redux處理資料
基於一切的經驗都是超級簡單的，就像你有一個物件，你把它交給一個Vue例項，它就變成了Reactive響應式的，每當你改變它時，資料就會自動更新，當你構建原型或試圖獲得概念證明時，這實際上非常有用，因為 - 它與我們對事物的思考方式一致，當我們想要在介面中更改某些內容時，會有一些相應的狀態需要更改。

不變性和函數語言程式設計今天變得越來越流行，但最終如果你想到Redux採取Action方式處理資料，然後返回不可變資料的複製副本，好像是一種改變狀態的奇特的方式。(banq注：Event事件概念還是不容易被大眾直覺接受)

Vue只是試圖堅持我們大多數人最直觀的方式 ，特別適合那些不願意重度學習函式程式設計的人，更願意在直覺方式考慮事情原理的人，

Redux和所有與Flux相關的模式被發明是用來處理大規模系統，
是為了處理狀態變化非常複雜的情況，可能還希望與擁有多個開發人員的團隊進行協作。在這種情況下，明確可能發生變化的內容，以及能夠在除錯時跟蹤實際發生變化的內容變得更加重要（banq注：事件溯源event sourcing）。

Vuex是嚴重受Flux和Redux激勵和影響,但是最終卻是Flux的一個特殊版本，能很好地處理可變性和Vue的響應系統。

我只是覺得Flux，甚至是Redux，更像是一種管理狀態而非特定實現的模式，我們想要實現共同目標是一樣的，就是讓狀態變化變得可預測，可維護，並使程式碼的意圖更容易被其他開發人員理解，我認為如果我們能夠保留這些特徵，那麼你的狀態是直接被修改，還是返回的是資料被修改的動作（導致狀態被修改的事件）並不重要。(banq注：Event Sourcing的概念不容易被理解。)

返回不可變的資料修改動作真正好處是：你可以自然地獲得每個狀態更改的快照（banq注：可以追溯狀態改變的原因，但是帶來複雜性和讀取效能問題）。事實證明，在大多數情況下，在Vuex中stringify出一個狀態很快，除非你要撤消/重做所有完整快照。在大多數情況下，它足夠快，可以捕獲你想要跟蹤的狀態的快照。

最後，React社群重視不可變性的另一個原因是因為它可以更容易地最佳化React元件呈現。(banq注：不可變性是函式正規化的靈魂，一榮俱榮。)

當你使用Vuex和Redux時，最終的開發體驗實際上非常相似，因為唯一的區別在於你如何改變狀態，而且Vuex更直接，就像你正常改變狀態一樣，

我覺得像Rx observables這樣的東西在這方面發揮作用，因為我發現關於Flux的核心思想是使用者會發出Action行動，而這些行動實際上有點像原始意圖。開發人員仍然負責的大部分工作是將這些意圖轉化為實際的狀態改變(banq注：命令導致狀態改變)。因此，當與非同步操作結合時，該過程變得非常複雜，我認為這就是Rx很適合的地方

當您瞭解分派dispatch使用者操作給Rx時，它會被Rx轉換為你希望看到的最終狀態改變，並且系統會自動自動對映這些改變到Vue的更新。

Vue.js | Ray Shan