我不知道的 dumi
跨框架组件渲染
假设团队维护一个 React 组件库，文档用 dumi 构建。某天产品线提出需求：需要在 Vue 技术栈的项目文档中，嵌入这些 React 组件的实时预览。
React, dumi
// 共 18 篇文章
假设团队维护一个 React 组件库，文档用 dumi 构建。某天产品线提出需求：需要在 Vue 技术栈的项目文档中，嵌入这些 React 组件的实时预览。
很多人以为 React Server Components（RSC）就是 SSR 的升级版——"以前在服务端渲染 HTML，现在换了个更好的方式"。但实际上，RSC 和 SSR 解决的是完全不同的问题，产出的东西也不一样，它们更像是两个可以叠加使用的独立技术层。
一个前端项目里同时跑两个版本的 React？听起来像是在自找麻烦。但在微前端架构和大型遗留项目中，这种需求真实存在——而且不是"能不能"的问题，是"怎么安全地做到"的问题。
React 组件是构建 UI 的基本单元，但组件之间如何共享逻辑，一直是一个棘手的问题。不同于工具函数的纯计算复用，React 要复用的往往是"带状态的逻辑"——比如追踪鼠标位置、监听窗口大小、管理表单校验。这类逻辑和组件的生命周期、状态管理深度绑定，没法简单地抽成一个函数。
React 19 于 2024 年底正式发布。这个版本带来的变化不是"多了几个新 API"那么简单——它在编译层面、数据交互层面和异步处理层面同时发力，试图从根本上减少 React 开发中最常见的两类样板代码：手动性能优化和手动异步状态管理。
在 React 项目里用 i18next，很多人一遇到翻译就条件反射般地用 Trans 组件。但实际上，大部分场景 t() 函数就够了，Trans 只在特定条件下才有存在的必要。搞不清两者的边界，轻则代码臃肿，重则引入不必要的渲染开销。
很多人以为 React Router 就是一个"URL 到组件的映射表"——配置好 path 和 component，剩下的它帮你搞定。能用是能用，但要问 为什么不会刷新页面、BrowserRouter 和 HashRouter 到底在监听什么事件、嵌套路由的 是怎么知…
很多人以为 JSX 就是在 JavaScript 里写 HTML，但实际上浏览器根本不认识 JSX。它既不是合法的 JavaScript，也不是真正的 HTML——它是一层语法糖，需要经过编译才能执行。
几乎每个 React 初学者都会撞上同一个困惑：调了 setCount，紧接着打印 count，发现值没变。于是搜索引擎告诉你——"useState 是异步的"。
上一篇讲了 useState 的批量更新和 Hook 链表机制。但 React 的 Hook 体系远不止状态管理——副作用处理、跨层级通信、性能优化，每一个场景都有对应的 Hook。这些 Hook 单独看都不难，但很多人以为掌握了用法就等于理解了原理，结果在实际项目中踩了各种坑。
React 组件之间要共享数据，方式不止一种。从最常见的 Props 到 Context，再到 Ref 暴露子组件方法，每一种都有各自的适用场景和陷阱。但组件通信只是前半段——当多个组件反复写着相同的状态逻辑时，如何把这些逻辑抽离成可复用的单元，才是 Hooks 体系真正的威力…
React 应用中，一个子组件的渲染错误如果没有被捕获，会导致整棵组件树卸载——也就是白屏。从 React 16 开始，这个行为是刻意设计的：React 团队认为，显示一个损坏的 UI 比完全不显示更危险，因为损坏的 UI 可能导致用户做出错误操作（比如支付页面上金额显示错误）。
很多人对 Redux 的理解停留在"一个全局状态管理工具"的层面——Store 存数据、Action 描述变更、Reducer 算新值。用起来没问题，但要问 dispatch 之后到底经历了什么、中间件为什么是三层柯里化函数、Immutability 为什么不是"建议"而是"硬…
执行 npm install react 之后，大多数人会紧跟一条 npm install react-dom，然后再也不会想起这件事。两个包装完，开始写组件，一切理所当然。
很多人以为 Fiber 只是 React 16 引入的一种新数据结构，但实际上，它是一整套调度系统——包含数据结构、遍历算法、时间分片机制和优先级模型。React 团队花了两年重写核心引擎，不是为了换个数据结构，而是为了让渲染这件事变得"可商量"。
React 的类组件生命周期曾经是面试高频题，很多人能背出从 componentWillMount 到 componentWillUnmount 的完整流程。但从 React 16.3 开始，三个 Will* 系列方法被标记为 UNSAFE_，到 React 18 已经不建议使…
React 处理表单的方式和原生 HTML 有一个根本性的分歧：表单数据的"真相源"（Source of Truth）在哪里？
React 组件渲染到 DOM 的位置，通常由它在组件树中的位置决定——父组件在哪个 DOM 节点下，子组件就渲染在那个节点内部。这在绝大多数场景下没有问题，但有一类 UI 元素天然需要"跳出"父组件的 DOM 结构：模态框、Toast 提示、Tooltip 浮层。