几个月前，我冒险重构了我已经开发了一段时间的 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中文网其他相关文章！
