幾個月前,我冒險重構了我已經開發了一段時間的 SaaS 應用程式的部分內容。我們有 Redux 在那裡,做它的事情,管理全域狀態。但感覺有些不對勁——程式碼庫變得越來越龐大,Redux 開始感覺……沉重。你知道嗎,就像你在背包裡放了幾個月沒碰過的東西?就是這種感覺。
但隨著我們的應用程式的發展,複雜性也隨之增加。 Redux 開始感覺不像是解決方案,而更像是一個問題。我們編寫的樣板檔案多於實際邏輯。
有一天,在與另一個 Redux 相關的 bug 作鬥爭時,我偶然發現了 React Query。經過一番研究,我發現了 React Query。我聽過很多關於它的討論,但我從未想過它可以完全取代 Redux。然後我就嘗試了一下。
之前(使用 Redux):
// Action const fetchUserData = (userId) => async (dispatch) => { dispatch({ type: 'FETCH_USER_REQUEST' }); try { const response = await api.fetchUser(userId); dispatch({ type: 'FETCH_USER_SUCCESS', payload: response.data }); } catch (error) { dispatch({ type: 'FETCH_USER_FAILURE', error }); } }; // Reducer const userReducer = (state = initialState, action) => { switch (action.type) { case 'FETCH_USER_REQUEST': return { ...state, loading: true }; case 'FETCH_USER_SUCCESS': return { ...state, loading: false, data: action.payload }; case 'FETCH_USER_FAILURE': return { ...state, loading: false, error: action.error }; default: return state; } }; // Component const UserProfile = ({ userId, fetchUserData, userData, loading, error }) => { useEffect(() => { fetchUserData(userId); }, [userId]); if (loading) return <Spinner />; if (error) return <Error message={error.message} />; return <UserInfo user={userData} />; }; const mapStateToProps = (state) => ({ userData: state.user.data, loading: state.user.loading, error: state.user.error, }); export default connect(mapStateToProps, { fetchUserData })(UserProfile);
之後(使用 React 查詢):
const useUserData = (userId) => { return useQuery(['user', userId], () => api.fetchUser(userId)); }; const UserProfile = ({ userId }) => { const { data, isLoading, error } = useUserData(userId); if (isLoading) return <Spinner />; if (error) return <Error message={error.message} />; return <UserInfo user={data} />; }; export default UserProfile;
React Query 為我們完成了大部分繁重的工作,而不是手動獲取資料、編寫減速器、調度操作,然後更新儲存。將其與一些精心設計的自訂掛鉤配對,我們就擁有了一個精益、平均的狀態管理機器。
現在,請不要誤會我的意思。 Redux 不是惡魔。它是一個強大的工具,有其一席之地。如果您正在建立具有複雜客戶端狀態的應用程序,則需要在許多不相關的元件之間共享,如果您正在使用深度嵌套的狀態,或者如果您需要對應用程式的流程進行更明確的控制,但對於90 % 的情況下,尤其是處理伺服器狀態時,React Query 自訂掛鉤就足夠了。
那麼,為什麼要大驚小怪呢?有時,身為開發人員,我們會陷入使用熟悉的工具的陷阱,即使有更好的工具。這就是我和 Redux 發生的事情。我陷入了舊的方式,認為 Redux 是在大型應用程式中管理狀態的唯一方法。我的意思是,整個網路都在說「要嘛 Redux,要嘛破產!」對嗎?
最重要的是:透過刪除 Redux,我們實際上使我們的應用程式更具可擴展性。違反直覺,對吧?但想想 - 透過 React Query 處理我們的伺服器狀態和管理本地狀態的自訂鉤子,我們有一個明確的關注點分離。我們應用程式的每個部分都變得更加模組化並且更易於推理。
老實說,在過去的幾個月裡,我很少看到 React Query 無法滿足我的需求的情況。
那麼,Redux 死了嗎?也許不是,但絕對不是以前的全明星了。用於在現代 React 應用程式中處理伺服器狀態
所以,你就有了。我們從 Redux 成癮到 React Query 啟蒙之旅。這並不總是那麼容易——有一些懷疑的時刻、深夜的調試會議以及不止幾次摀臉。但最終,這是值得的。
如果您在自己的應用程式中感到 Redux 陷入困境,我鼓勵您退一步問自己:您真的需要它嗎?您可能會對答案感到驚訝。
有時少即是多。尤其是在狀態管理方面。現在請原諒,我還有一些要刪除的減速器。快樂編碼!
以上是Redux 死了嗎?為什麼我將 Redux 從 SaaS 應用程式中踢出的詳細內容。更多資訊請關注PHP中文網其他相關文章!