8.2 代码规范：Solid风格与React习惯的差异清单
8.2 代码规范：Solid 风格与 React 习惯的差异清单
本节摘要：混着写的代码库最难维护——一半组件用 React 习惯写（解构 props、滥用 useMemo），一半用 Solid 风格。本节把两者差异固化成一份可执行的评审清单：命名前缀、props 访问、控制流选择、组件拆分标准、格式化配置，目标是让"看起来像 React 的 Solid 代码"在评审环节就被拦下。
规范的价值在混仓期最大化。全 Solid 的绿地项目靠习惯就能维持一致性；从 React 迁来的团队最缺的是"什么是地道写法"的共识——每个人都在用自己最熟悉的方式写能跑的代码。这份清单按评审频率排序，前四条覆盖了实践中绝大多数的风格偏差。
清单一：命名与结构
- 响应式工厂用 create 前缀：组合原语一律
createXxx，对应 React 的useXxx。语义差别要写进规范注释：use 暗示"每次渲染重新执行"，create 强调"创建一次终身工作"。 - 组件就是普通函数：不需要 memo 包装、不需要 forwardRef 转发（ref 是普通属性），定义方式箭头函数或函数声明皆可，团队统一即可。
- 一个原语一个职责：React 圈流行的"巨无霸自定义 Hook"在 Solid 里应拆成小原语组合——没有调用规则限制后，拆分的唯一成本是文件组织。
清单二：props 与数据访问
- props 禁止解构：评审最高频拦截项。保持
props.xxx访问；默认值用mergeProps，拆分透传用splitProps。 - store 访问保持路径：
state.user.name合法，const { user } = state违规。需要子对象传递时，传访问函数或用mergeProps包一层保持取值器。 - Signal 返回值不拆散导出：模块级信号导出
[get, set]对，或封成对象带语义方法（session.user()、session.login()），禁止裸导出 setter 让调用方随意改。
清单三：控制流与渲染
- 列表一律 For 或 Index：表达式里出现
.map(渲染 JSX 即违规（4.3 详述）。纯数据变换的 map（算个新数组再交给 For）合法。 - 分支超过两路用 Switch：三元嵌套超过一层就换
Switch加Match，评审可机械执行。 - 条件优先 Show：
&&短路渲染在简单场景可用，带 fallback 或需要真值收窄时必须Show。
清单四：副作用与生命周期
- Effect 里不做派生计算：算出来的值应写进 Memo 供声明式消费，Effect 只与外界（DOM、网络、定时器、第三方实例）打交道。对应 React 圈"不要在 useEffect 里 setState 链式算状态"的老告诫，理由更硬。
- 清理逻辑就近 onCleanup：登记清理的位置紧挨着创建资源的语句，不集中写在卸载钩子里——Solid 也没有卸载钩子。
- 全局逻辑必须 createRoot 包裹：组件外创建响应式实体是规范动作而非逃生舱。
清单五：格式化与工具
格式化层面两框架可以完全一致——同用一套编辑器格式化配置与代码风格即可；差异集中在语义 lint。React 的 hooks 规则插件（检查依赖数组、条件 Hook）在 Solid 里应当关闭，换成 Solid 专属的 lint 规则集（社区插件提供"禁止解构 props""禁止表达式渲染列表"等检查）。ESLint 配置里做一次替换，清单二与清单三的大半条目就自动化了。
// 评审清单速查卡（可贴进合并请求模板） // 1. props 有没有被解构？ // 2. JSX 里有没有渲染列表的 map？ // 3. 有没有残留的 useMemo、useCallback、memo？ // 4. Effect 里有没有算派生状态？ // 5. store 有没有被展开？ // 6. 清理逻辑有没有就近 onCleanup？
组件拆分标准的变化
React 风格里"拆组件"常带着性能动机：把重渲染的热区隔离出去。Solid 拆组件的动机只剩组织与复用——拆不拆对性能没有影响，因为组件边界不参与更新传播。这带来一个反直觉的规范条目：Solid 里"为性能而拆"是无效动作，"为复用而拆"才成立。 相应地，一屏几十个小组件的细碎拆法失去了意义，组件可以更大、更贴近业务块。从 React 迁来的团队要先戒掉"预防性拆分"的瘾。
对照表收束本章：
| 评审项 | React 合理习惯 | Solid 地道写法 |
|---|---|---|
| 复用逻辑 | useXxx Hook | createXxx 原语 |
| props 接口 | 解构加默认值 | mergeProps 加 splitProps |
| 渲染列表 | map 加 key | For 或 Index |
| 性能拆组件 | memo 加热区隔离 | 按业务块组织，拆分与性能无关 |
| 状态放置 | 上提到公共父组件 | 信号放最近消费处或模块级 |
| 格式化 | 通用配置 | 与 React 完全一致 |
💡 把"状态放最近消费处"单独强调：React 因提升状态的成本低（props 通道现成），习惯把状态上提；Solid 里状态放越近，依赖线越短，图越干净。迁移时很多"提升"应当撤销。
规范落地的三件套
清单写出来只算完成了一半，落地靠三件套：模板、自动化、流程。模板指合并请求描述里内置评审速查卡（本节开头的六问），提交者自查打勾；自动化指 8.2 提到的 lint 规则替换——hooks 规则下架、Solid 规则集上架，能机械拦截的就不消耗人力；流程指争议裁决路径——清单没覆盖的写法争议，由周会裁决后补进清单并注明日期，让规范文档有版本生命而不是一次性布告。
问题：格式化与命名风格要不要为 Solid 单独一套？
不需要。格式化（缩进、引号、行宽）与框架无关，全仓统一一套即可，混仓期尤其不要按目录分风格——那会让评审在无关紧要的维度上消耗注意力。命名风格里只有一件事需要新约定：create 前缀与 use 前缀的语义区分（3.3 讲过），写成两行规范足矣。把规范预算花在数据访问与控制流这些真正的语义分界上，别花在颜值上。
本节要点回顾
- 十二条清单五组：命名、props、控制流、副作用、工具，评审按序过。
- lint 自动化半壁清单：换掉 hooks 规则，装 Solid 规则集。
- 拆分动机变了：为性能拆是无效动作，为复用拆才成立。
- 状态放最近消费处：依赖线短，图才干净，撤销不必要的提升。
下一章解决"跑不起来怎么办"与"上线稳不稳"——测试、调试与部署的完整工具面。