https://medium.com/@tomchentw/framework-1b133c6e320d#.u62x5757o
https://medium.com/@tomchentw/framework-a3befb7db904#.4mihsnswl
封裝程式邏輯
React.createClass 的方式來產生一組Component元件(native ES6 class support is on the road)，這點跟其他Framework很像，但是React對待元件狀態有嚴格規定：
this.props為given properties (by owner)，不能修改，也不應該被修改
this.state為自身的狀態物件，所有的狀態都源自於此（也只該源至於此，否則就是你的問題）
React透過Framework給出強烈的約束行為，限制你的思考方向，因此我們較容易寫出清楚的程式碼：因為狀態的來源只有一個this.state。也因為我們減少狀態來源到只有一個地方(Single Source of Truth!)，元件封裝變得容易許多，邏輯部分也只要搞清楚this.state的變化就好。
達成復用性
基於「封裝程式邏輯」的理由，我們剛剛講了this.state被封裝在元件裡面，因此對於使用這個元件的人(owner)而言，它要怎麼去影響元件的狀態？其實就是根據owner傳進去給該元件的props來決定。你可以說，當你決定好這個元件要回應哪些props的時候，介面就已經訂完了，復用性根本連想都不必想，它已經內化在整個React的核心價值，寫好一個元件後，復用性就在那裡：各位，我們準備好了。
你會想，不，哪有那麼好康的事？事實上，正因React完美達到這兩個聖杯，幾乎所有在這裏撞到牆的Web Developers，一使用後便瘋狂的愛上它，社群幾乎是瞬間飆漲起來，非常之可怕。我誠摯的推薦大家好好的玩一下React，新一波的技術革命正在醞釀！
「單向資料流」可以說是整個React/flux架構最核心的想法，而且也正因為單向資料流的實現，我們可以輕易實現Computer Science的聖杯「Single Source of Truth」，在flux架構下，所有的資訊來源只有Store(s)，沒有第二種可能；這時候，React的props相對於Store而言就收斂成另一種state。
Single Source of Truth的好處非常多，以React Component來講，這讓元件的行為變得可預期，測試更好寫了。即使在不寫測試的情況下，唯一真相會大幅提高元件可信賴度（這邊可以另外開文寫了）。
我現在選擇的Framework是React.js與Flux.js，它提供三大好處解決長久以來開發的問題：
Custom Element：真正Reusable、Scalable的客製化元件。
單向資料流：易除錯、架構清晰且邏輯完整的思考模式。
Single Source of Truth：核心思想。
我相信只要是寫過Single Page Application的開發者，都會知道這三點有多麼重要，而React/flux幫我們優雅地實現了。再不試試看損失的機會成本越大呀！