幾個月前，我冒險重構了我已經開發了一段時間的 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中文網其他相關文章！
