React 表单提交的 pending 态要先于按钮禁用
· 阅读需 2 分钟
很多表单页面对提交态的处理都很机械:点一下按钮,按钮变灰,结束。可真正的体验问题往往不在“有没有禁用”,而在用户是否明确知道请求已经开始、当前能不能继续操作、如果慢了应该看哪里。
很多表单页面对提交态的处理都很机械:点一下按钮,按钮变灰,结束。可真正的体验问题往往不在“有没有禁用”,而在用户是否明确知道请求已经开始、当前能不能继续操作、如果慢了应该看哪里。
React 18 在 2022 年真正进入大家视野后,最吸引眼球的关键词之一就是并发渲染。很多人第一次看到时会觉得它像是一个很底层的概念,但它背后其实对应的是用户体验层面的优化空间。
前端页面一旦有异步数据流,状态重置就是迟早要面对的问题。筛选条件变了、数据源切了、详情页返回了,看似只是一次普通交互,但如果旧状态还残留在组件里,界面很容易表现出“偶现错乱”。
React 18 上线后,不少项目第一次在开发环境里看到副作用执行两次,直觉都会觉得“框架是不是出问题了”。但我自己的经验是,StrictMode 暴露的往往不是框架 bug,而是我们本来就没处理好的副作用和初始化假设。
只要页面里有中大型列表,性能问题迟早会出现。很多人这时会本能地去加 memo、useMemo、useCallback,但我越来越觉得,真正决定列表是否好维护的,往往不是有没有做缓存,而是渲染边界有没有拆清楚。
React 18 的并发能力第一次接触时最容易让人兴奋,但真正写进业务后,我觉得最难的不是 startTransition 这个 API,而是你到底知不知道哪些更新应该立刻响应,哪些更新可以稍微“让一下”。



