2014-12-03 102 views
30

作爲一個具有良好的實踐性AngularJS經驗的開發人員,我如何調整使用React在Flux中編寫Web應用程序的心智模式?從AngularJS到Flux - React方法

我不是在尋找一個流量+陣營VS角答案(已經很多,網上的),但我會知道什麼是在兩個「思維」的最大差異:事先,我被引入The Angular Way;相對而言,什麼是The React Way

在我離開的角度宇宙並過渡到流量,哪些關鍵的東西我需要開始關注

差異首先,現在的相似之處:AngularJS非常有見地,並有一些非常大的禁忌,像 - 不要把UI/DOM代碼放在控制器中。 React最大的禁忌和意見是什麼?

最後但並非最不重要的,Facebook的指的是磁通,一個替代MVC,但我在看它 - REACT爲視圖引擎,商店集中在單域模型容器,以及調度員和行動組成一個控制器。那麼這不是真的MVC有不同的名字嗎?

+0

我沒有Angular的經驗,所以很難解釋它們之間的差異和轉換過程。然而,關於問題的第二部分:React僅僅是來自MVC的V,我會將它與Mustache/Marionette進行比較。 Flux有存儲和調度器,並與React一起創建MVCish結構。你也可以很容易地用Backbone替換Flux。 – daniula 2014-12-03 07:30:50

+0

在我看來,Flux是一種反模式。將所有商店連接到單個調度程序,無論其抽象級別和責任如何,都會導致大規模調度程序塊發生管理噩夢。 – 2015-06-22 14:04:45

+1

@DmitriZaitsev Flux不強制要求每頁只有一個調度程序。您可以擁有儘可能多的調度程序,以便在同一頁面上實際處理不同類型的操作。 – bluecollarcoder 2015-08-25 21:13:12

回答

52

我會讓別人和Angular做比較/對比,但這裏有一些問題的答案。

那麼這不是真正的MVC與不同的名稱?

Flux中數據/邏輯層和視圖層之間的關注分離的存在不會使其成爲MVC。許多其他模式也有類似的分裂,最明顯的是CQRS,可以說是Flux最親密的表兄弟。在MVC中,Flux中沒有控制器。操作和分派器不等於控制器。控制器視圖非常接近,但其控制器方面實際上非常有限。一個關鍵的區別是MVC控制器包含應用程序邏輯並且在模型上執行。相比之下,Flux存儲包含所有的應用程序邏輯並且沒有設置器。

當我離開Angular宇宙並轉換到Flux時,我需要開始關注哪些關鍵事項?通量的

鍵值:

  • 簡單了複雜性。
  • 程序員的心智模式至少和代碼本身一樣重要。
  • 應用程序的某些部分應該高度分離並儘可能少地瞭解其他部分。
  • 控制反轉:所有控制都應該存在於管理狀態的商店中。店鋪沒有采取行動,而是採取行動通知。
  • 應用程序在增長時應該保持彈性和靈活性,以便更快更輕鬆地開發新的意想不到的功能。
  • 在流量

重要概念:

  • 單向數據流:操作→調度→商店→查看
    • 狀態每變化和被派遣行動的所有新數據開始。
    • 這個四步數據流是Flux程序員的核心心智模型。
  • 甲調度引起的應用程序狀態的應用程序範圍內轉換。
    • 這是一時的,產生變化的快照。這很容易推理。
    • 我們不能在調度時調度並保持這種簡單性。因此,任何必然的改變都必須由原始行爲驅動。
  • 流量商店域模型,而不是ORM模型。它們包含所有邏輯並管理應用程序中特定邏輯域的所有狀態。它們可能包含集合,單數值或兩者的組合。
  • 通量假定得出的數據 - 其中一個店面依賴於另一家商店的變化 - 在複雜應用中的模型或存儲管理標準化的數據的可能性。爲了解決這個問題,Flux Dispatcher應該公開一個機制來聲明性地管理該商店內的這種依賴。在Facebook的調度程序中,這是通過waitFor()方法完成的。這允許一家商店等待另一家商店對行動做出迴應,然後再進行自己的迴應。

焊劑應用程序的主要組成部分:

  • 操作:對象文本包含新數據和特定類型的,允許 商店辨別是否是有關其結構域。
  • 調度員:通過回調 向註冊人(商店)分配有效載荷(動作)的回調註冊表。它沒有自己的智慧。所有的情報都在商店裏。
  • 商店:與所述分派器寄存器本身,每當在其狀態發生改變時發出「改變」事件域模型。
  • 控制器視圖:查看組件樹根部附近的組件。他們傾聽商店中的「變化」事件,並通過商店暴露的吸氣方法檢索新數據並將其傳遞給他們的孩子來回應此事件。控制器視圖和視圖之間的唯一區別是這種偵聽功能。
  • 瀏覽:控制器視點分量的無國籍兒童,接收和沿着數據傳遞,很像純函數。視圖和控制器視圖通常用React實現,因爲它提供了隨意重新渲染而性能損失很小的能力。
  • Utils:可在不同模塊之間輕鬆共享的純函數庫。

概述,深入:http://facebook.github.io/flux/docs/overview.html

教程:http://facebook.github.io/flux/docs/todo-list.html

例子:https://github.com/facebook/flux/tree/master/examples

操作和調度:http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

測試:http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

更多在野外:http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html

+0

謝謝。你能否擴展關鍵概念#4?特別是關於這一點:「Flux認爲,派生數據 - 其中一家商店依賴於另一家商店的變化 - 是模型或商店管理規範化數據的複雜應用程序中的一個可能性。」 (機制部分很清楚)。謝謝。 – pilau 2014-12-03 09:05:45

+1

當應用程序規範化數據時,即在兩個地方沒有重複數據(因爲這樣做很難維護)時,我們經常遇到需要在Store B中存儲數據A的情況。例如,在構建賀卡的應用中的ImageStore vs. ThemeStore。每個主題可以包含不同的最大數量的圖像。 ImageStore需要知道選擇了哪個主題,因此它知道它可以標記爲有效的數量。當調用THEME_SELECTED類型的動作時,ImageStore需要waitFor ThemeStore,然後獲取所選主題的最大值。 – fisherwebdev 2014-12-03 09:23:11

+2

處理衍生數據實際上是Flux在Facebook上開發的原始原因。然而,後來出現了許多好處。 – fisherwebdev 2014-12-03 09:25:00

相關問題