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