首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >别再这样用useState了!这个被99%前端忽视的设计模式,正在悄悄拯救代码

别再这样用useState了!这个被99%前端忽视的设计模式,正在悄悄拯救代码

作者头像
前端达人
发布2025-10-09 13:08:39
发布2025-10-09 13:08:39
1190
举报
文章被收录于专栏:前端达人前端达人

前端React开发中被忽视的设计模式:状态机其实没你想的那么复杂

不是什么新技术,就是那个计算机课上学过的状态机。但用好了,能让你的代码清爽不少。

从一个真实案例说起

前段时间重构一个表单组件,发现代码里有这样的状态管理:

代码语言:javascript
复制
const [isLoading, setIsLoading] = useState(false);
const [isSubmitted, setIsSubmitted] = useState(false);
const [hasError, setHasError] = useState(false);
const [isEditing, setIsEditing] = useState(false);
const [showModal, setShowModal] = useState(false);

看起来还行,但问题在于这些状态之间的关系完全靠开发者自觉维护。比如isLoading为true时,isEditing应该是false,但代码里没有强制约束。

结果就是偶尔会出现一些奇怪的组合:按钮既在加载又可以编辑,或者错误提示和成功提示同时出现。

状态机:其实就是把状态管理规范化

状态机听起来很学术,但核心思想很简单:明确定义所有可能的状态,以及状态之间如何转换

用状态机重写上面的逻辑:

代码语言:javascript
复制
const formMachine = createMachine({
id: 'form',
initial: 'idle',
states: {
    idle: {
      on: { EDIT: 'editing', SUBMIT: 'loading' }
    },
    editing: {
      on: { SAVE: 'loading', CANCEL: 'idle' }
    },
    loading: {
      on: { SUCCESS: 'success', ERROR: 'error' }
    },
    success: {
      on: { RESET: 'idle' }
    },
    error: {
      on: { RETRY: 'loading', RESET: 'idle' }
    }
  }
});

好处很明显:

  • 状态清晰:一眼就能看出有哪些状态
  • 转换明确:什么情况下可以从A状态到B状态
  • 不会出现非法状态:比如同时loading和editing

什么时候值得用状态机?

不是所有场景都需要状态机,我的经验是:

适合用的场景:

  • 表单(有编辑、提交、成功、失败等状态)
  • 模态框(打开、关闭、加载等)
  • 多步骤流程(注册向导、支付流程等)
  • 任何有明确"生命周期"的组件

不太需要的场景:

  • 简单的开关状态(显示/隐藏)
  • 纯展示组件
  • 只有1-2个状态的简单逻辑

XState:不错的工具,但有学习成本

如果要在项目中使用状态机,XState是个不错的选择:

代码语言:javascript
复制
import { useMachine } from '@xstate/react';

function FormComponent() {
  const [state, send] = useMachine(formMachine);

  return (
    <div>
      {state.matches('loading') && <LoadingSpinner />}
      {state.matches('error') && <ErrorMessage />}
      
      <button 
        onClick={() => send('SUBMIT')}
        disabled={!state.can('SUBMIT')}
      >
        {state.matches('loading') ? '提交中...' : '提交'}
      </button>
    </div>
  );
}

优点:

  • API设计得不错,和React集成度高
  • 有可视化工具,能生成状态图
  • 支持复杂场景(嵌套状态、并行状态等)

缺点:

  • 学习曲线确实存在
  • 小项目可能有点重
  • 团队需要统一理解

一个更轻量的思路

如果觉得XState太重,也可以自己实现简单版本:

代码语言:javascript
复制
function useStateMachine(config) {
const [state, setState] = useState(config.initial);

const send = (event) => {
    const currentState = config.states[state];
    const nextState = currentState.on[event];
    if (nextState) {
      setState(nextState);
    }
  };

return [state, send];
}

这样既能享受状态机的好处,又不会引入太多复杂度。

实际建议

对于个人项目:试试看,特别是有复杂状态逻辑的时候。即使只是在纸上画个状态图,也能帮你理清思路。

对于团队项目:可以从小范围开始,比如重构一个比较复杂的表单组件。让团队感受一下效果,再决定是否大规模采用。

对于新手:不用急着上手,先把基础的状态管理搞熟练。但可以了解一下这个思路,对理解复杂状态逻辑有帮助。

结语

状态机不是什么银弹,但确实是个有用的工具。特别是当你的组件状态开始变得复杂,各种if-else嵌套让人头疼的时候。

关键是要根据实际情况选择。简单的逻辑用useState就够了,复杂的状态管理可以考虑状态机。

你在项目中遇到过复杂的状态管理问题吗?欢迎在评论区分享你的解决方案!


🔖 如果觉得有用,欢迎关注。下期聊聊"前端性能优化的几个实用技巧"

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-09-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 前端达人 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 从一个真实案例说起
  • 状态机:其实就是把状态管理规范化
  • 什么时候值得用状态机?
  • XState:不错的工具,但有学习成本
  • 一个更轻量的思路
  • 实际建议
  • 结语
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档