React函数组件Prop计算用常量/state/useEffect/useMemo哪种符合最佳实践？

1、哪种实现方案最符合React最佳实践？ #

Comp1是最符合最佳实践的实现。
原因很简单：numToStr是纯转换函数，没有任何副作用、也不需要异步操作，完全可以在组件渲染过程中直接计算返回结果，不需要引入useState、useEffect、useMemo这些额外的React钩子，代码最简洁易懂，也没有多余的逻辑负担。

2、四种实现分别对性能有什么影响？ #

• Comp1：性能最优，没有任何额外钩子的运行开销，也不会触发多余渲染，内存占用最低。唯一的计算消耗就是numToStr的执行时间，对这类简单转换函数来说可以忽略不计。
• Comp2：性能略低于Comp1，多了useState的初始化、状态存储的少量开销，不过整体差异极小。但这套实现存在逻辑缺陷：如果后续num属性发生变化，状态不会同步更新，展示值会和传入值不一致。
• Comp3：性能最差。首先首次渲染时numAsStr是undefined，页面会先渲染空内容，等到组件挂载完成后useEffect执行，调用setNumAsStr会触发组件第二次渲染，等于平白多了一次完整的组件渲染、DOM更新流程，额外开销非常明显。
• Comp4：性能略低于Comp1，多了useMemo的缓存创建、对比的少量开销，属于典型的过度优化。同样存在和Comp2一样的逻辑缺陷：如果num更新，缓存不会重新计算，展示值会过时。

3、已知组件仅渲染一次的前提，是否会影响实现方案的选择？ #

哪怕确定组件仅渲染一次，核心选择逻辑也不会变，Comp1依然是最优选择。
仅渲染一次的前提只能规避Comp2、Comp4的逻辑缺陷（因为num不会变，不需要更新），但也不会改变Comp3需要两次渲染的问题，也不会抵消其他三种实现额外带的钩子开销，反而更不需要用多余的钩子做缓存、状态存储之类的操作，直接用最简单的Comp1就足够。
只有当numToStr是计算量极大的重型函数（比如复杂的加密、批量数据处理），哪怕单次执行都会明显阻塞渲染时，才可以考虑用Comp2或者Comp4的方案提前做计算缓存，但这种场景非常少见。

4、是否应该忽略仅渲染一次的前提，将num添加到useEffect、useMemo的依赖数组中，支持监听prop变化的能力？ #

必须要把num添加到依赖数组中。
首先这是React官方的强制规范，eslint-plugin-react-hooks的规则会直接对缺少依赖的写法报错，不符合规范的代码在未来React版本升级时也可能出现不可预期的运行问题。
其次，"仅渲染一次"只是当前的业务前提，未来业务迭代很可能会调整组件的使用场景，如果漏加依赖，后续需要支持prop更新时就会出现难以排查的显示bug，属于无意义的技术债。
如果你确定组件永远不需要响应prop变化，那更合理的做法是直接去掉useEffect、useMemo这些钩子，改用Comp1的写法，从根源上避免依赖问题。

内容的提问来源于stack exchange，提问作者Eden Katabi