8 篇博文 含有标签「React18」

Next.js 13 刚出来时，大家最容易被 Server Component 这个概念吸引，因为它看起来像是在重新分配前后端渲染责任。但真开始上手以后，我觉得最难的不是语法本身，而是组件边界要重新思考。

做 React 项目时，很多人很自然会把“能不能复用”当成组件拆分的第一原则。但到了 React 18 这种并发渲染语境下，我越来越觉得，组件的渲染责任是否清晰，很多时候比复用程度本身更重要。

很多表单页面对提交态的处理都很机械：点一下按钮，按钮变灰，结束。可真正的体验问题往往不在“有没有禁用”，而在用户是否明确知道请求已经开始、当前能不能继续操作、如果慢了应该看哪里。

React 18 在 2022 年真正进入大家视野后，最吸引眼球的关键词之一就是并发渲染。很多人第一次看到时会觉得它像是一个很底层的概念，但它背后其实对应的是用户体验层面的优化空间。

前端页面一旦有异步数据流，状态重置就是迟早要面对的问题。筛选条件变了、数据源切了、详情页返回了，看似只是一次普通交互，但如果旧状态还残留在组件里，界面很容易表现出“偶现错乱”。

React 18 上线后，不少项目第一次在开发环境里看到副作用执行两次，直觉都会觉得“框架是不是出问题了”。但我自己的经验是，StrictMode 暴露的往往不是框架 bug，而是我们本来就没处理好的副作用和初始化假设。

只要页面里有中大型列表，性能问题迟早会出现。很多人这时会本能地去加 memo、useMemo、useCallback，但我越来越觉得，真正决定列表是否好维护的，往往不是有没有做缓存，而是渲染边界有没有拆清楚。

React 18 的并发能力第一次接触时最容易让人兴奋，但真正写进业务后，我觉得最难的不是 startTransition 这个 API，而是你到底知不知道哪些更新应该立刻响应，哪些更新可以稍微“让一下”。