Flux最佳實踐：存儲調度操作，Web API Utils中的AJAX調用？

Question

據我所知，這張圖片是大多數（如果不是全部）Flux程序員的終極指南。 考慮到這一點，我有幾個問題：

1. 在我的Web API Utils中調用所有$.ajax調用是否正確/強烈建議？
   • 回調調用動作創建者，在過程中傳遞數據
2. 如果我希望我的商店進行AJAX調用 ，我必須先調用Action Creator ，對吧？ 從Store直接調用Web API Utils中的函數是否根本不正確？
3. 是否有像從Store到Action Creators連接的虛擬單面箭頭？
   • 我有很多不通過視圖的操作
4. Dispatcher和Store之間有什么回調 ？
5. 什么是Web API ？ 這是您應用RESTful API的地方嗎？ 在某個地方有這樣的例子嗎？

6. 在我的一個Action Creators中是否可以使用邏輯（知道要調度哪個Action ）？ 基本上，此操作接收來自我的AJAX調用的響應。 這是一個片段：

    var TransportActions = { receiveProxyMessage: function (message, status, xhr) { switch (message) { case ProxyResponses.AUTHORIZED: AppDispatcher.dispatch({ type: ActionTypes.LOGIN_SUCCESS, reply: m }); break; case ProxyResponses.UNAUTHORIZED: AppDispatcher.dispatch({ type: ActionTypes.LOGIN_FAIL, reply: m }); break; ... } } } 

我在網上看到了很多不同的答案，但我仍然不確定如何將所有這些答案合並到我的應用程序中。 TYIA！

Answer 1

在我的Web API Utils中調用所有$ .ajax調用是否正確/強烈建議？ 回調調用動作創建者，在過程中傳遞數據。

是的，您應該將所有請求放入單個實體，即Web API Utils。 他們應該發送回復，以便任何商店可以選擇對他們采取行動。

我剛才寫了一篇博客文章，展示了如何處理請求的方法http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

如果我希望我的商店進行AJAX調用，我必須先調用Action Creator，對吧？ 從Store直接調用Web API Utils中的函數是否根本不正確？

這是一個很好的問題，就我所見，每個人都有一點不同。 Flux（來自Facebook）沒有提供完整的答案。

您通常可以采取兩種方法：

1. 您可以建立一個商店不應該“詢問”任何數據的論點，而只是簡化摘要操作並通知視圖。 這意味着如果存儲為空，則必須在組件內觸發“獲取”操作。 這意味着如果必須獲取數據，則必須檢查每個數據監聽視圖。 如果多個視圖偵聽同一個商店，這可能會導致代碼重復。

2. 商店是“聰明的”，因為如果他們被要求提供數據，他們會檢查他們是否確實有交付狀態。 如果他們不這樣做，他們會告訴API Utils獲取數據並將未決狀態返回給視圖。

   請注意，這“告訴API獲取數據”不是基於回調的操作，而是“一次又一次忘掉”。 一旦請求返回，API將分派操作。

我更喜歡選項2到選項1，我聽說Facebook團隊的Bill Fisher說他們也是這樣做的。 （見上文博文中某處的評論）

因此， 沒有它不是根本上的錯誤，從存放在我看來直接調用API。

是否有像從Store到Action Creators連接的虛擬單面箭頭？

根據您的Flux實施情況，可能會很好。

Dispatcher和Store之間有什么回調？

它們是唯一可以實際改變商店狀態的功能！ 每個商店都向Dispatcher注冊一個回調。 無論何時調度操作，都會調用所有回調。 每個回調決定是否必須在給定操作類型的情況下改變商店。 一些Flux庫試圖隱藏此實現細節。

什么是Web API？ 這是您應用RESTful API的地方嗎？ 在某個地方有這樣的例子嗎？

我認為在圖片中，Web API矩形代表實際的服務器，API Utils是調用服務器的（即$ .ajax或superagent）。 它很可能是一個服務於JSON的RESTful API。

一般建議：

Flux是一個相當寬松的概念，確切的實現從團隊變為團隊。 我注意到Facebook也隨着時間的推移在這里和那里改變了一些方法。 確切的周期沒有嚴格定義。 雖然有一些相當“固定”的東西：

1. 有一個Dispatcher可以將所有操作分派給所有商店，並且當時只允許一個操作來阻止事件鏈地獄。
2. 商店是行動接收者，所有州必須通過行動改變。
3. 行動是“火與忘”（沒有回調！）
4. 視圖從商店接收狀態並觸發操作

其他事情從實現到實現都有所不同

Answer 2

1. 在我的Web API Utils中調用所有$ .ajax調用是否正確/強烈建議？ 回調調用動作創建者，在過程中傳遞數據。

絕對。

2. 如果我希望我的商店進行AJAX調用，我必須先調用Action Creator，對吧？ 從Store直接調用Web API Utils中的函數是否根本不正確？

首先，問問自己為什么您的商店需要進行API調用。 我能想到的唯一原因是你想要在商店中緩存收到的數據（我這樣做）。

在最簡單的Flux實現中，所有Actions僅從View和Server創建。 例如，用戶訪問一個“個人”視圖，該視圖調用profileRequest行動的創建者，該ApiUtils被調用時，一些數據進來，一個ServerAction創建中， ProfileStore更新本身和ProfileView相應做。

使用緩存： ProfileView向ProfileStore詢問某個配置文件，商店沒有它，因此返回狀態為“loading”的空對象，並調用ApiUtils來獲取該配置文件（並忘記它）。 當調用結束時，將創建一個ServerAction ， ProfileStore將自行更新，等等。這很好。 你也可以從商店打電話和ActionCreator，但我沒有看到好處。

MartyJS做了類似的事情。 一些焊劑實施對承諾也是如此。

我認為重要的部分是：當數據返回系統時，將使用新數據調用ServerActionCreator。 然后流回商店。

我認為商店應該只查詢數據，所有狀態改變動作（更新的東西）都應該由用戶啟動（來自視圖）。 來自Facebook的工程師在這里寫到： https ： //news.ycombinator.com/item？id = 7719957

3. 是否有像從Store到Action Creators連接的虛擬單面箭頭？

如果你想讓你的商店變得聰明：是的。 如果你想讓你的應用變得簡單：不，請瀏覽視圖。

4. Dispatcher和Store之間有什么回調？

這些是您在商店中找到的調度處理程序。 調度員觸發一個動作，存儲偵聽此火災事件並對動作/有效負載執行某些操作。

5. 什么是Web API？ 這是您應用RESTful API的地方嗎？ 在某個地方有這樣的例子嗎？

這是你的ajax調用的地方。 通常這意味着一些REST API，但也可能是websockets或其他什么。 我一直很喜歡這個教程： http ： //fancypixel.github.io/blog/2015/01/29/react-plus-flux-backed-by-rails-api-part-2/

免責聲明：這些是我對Flux的解釋。 Flux本身並沒有真正解決獲取數據的問題，這就是他們在FB上提出Relay和GraphQL的原因