2017-04-12 96 views
1

也許我在想這個錯誤,但是我使用redux-thunk的一個常見模式是返回一個promise,以便在某些事情完成或失敗時我可以在容器對象中執行一些額外的操作。從Redux返回Promise Observable


使用咚爲例:

行動者:

const action = ({ data }) => (dispatch) => 
    fetch(`some http url`) 
    .then(response => { 
     if(response.ok) { 
      return response.json(); 
     } 

     return Promise.reject(response); 
    }) 

某處在連接組件:

this.props.action("Some Data") 
    .then(console.log) 
    .catch(error => console.error("ERROR")); 

是否有這樣做的清潔方法在Redux-Obs中有類似的東西ervable/Rxjs?基本上從行爲中返回一個承諾,稱爲史詩,當觀察結束後返回解析或拒絕。

回答

5

一般來說,當使用諸如redux-observable/redux-saga之類的東西時,我試圖讓人們遠離這些模式。相反,如果您正在等待您調度的更新商店狀態的操作,請依賴狀態更新本身或您的減速器存儲在狀態中的某種事務性元數據。例如{ transactions: { "123": { isPending: true, error: null } }

不過,如果你真的做想做的事,你可以編寫(或使用現有)的中間件,從dispatch返回一個承諾,當其他一些指定動作已分發(大概是由你的史詩,將解決)。 redux-wait-for-action就是一個例子(不是推薦,儘管我沒有用過)

請記住,Promise通常不是可取消的,所以你可能會意外地創建一個組件開始等待某個動作的情況,用戶離開該頁面和組件是卸載,而你還在等待其他行動 - 這以後可能會出現的怪事,就像如果他們回來到該頁面,等


如果你等待到副作用,屬於你的史詩。開啓一個史詩聽的單一動作,產生副作用,然後發出另一個動作來表示完成。另一部史詩聽取完成動作,然後開始另一個副作用,等等。如果你願意的話,你可以把它們全部放在一個整體史詩中,但是我覺得分離更容易進行測試和重用。

+0

可能會回答我自己的問題,但是如果行動中存在不可呈現的副作用,情況如何?使用上面的例子,假設我們想在'isPending'從true切換到false(從史詩取得完成)之後調用組件的'this.someInFunc()'。然後我們必須利用像componentWillReceiveProps()這樣的生命週期鉤子,並檢查reducer中的道具是否改變。 (?) – dpaulus

+1

每個人都沒有規則,但聽起來像屬於你的史詩般的邏輯。除了保持私有內部狀態的通用組件外,其他組件不應該包含那樣的業務邏輯。他們渲染DOM,並響應UI事件的調度動作,然後根據商店的狀態和道具重新渲染 - 就是這樣。 – jayphelps

+1

如果你想執行一個副作用,那麼完成後再做另一個,這對史詩來說是成熟的東西。發出一個單獨的動作來踢一連串的副作用,將在一個或多個史詩中處理。 – jayphelps