React Native中props存为state的益处、冗余判断与最佳实践

你贴出的代码里的number state属于完全冗余的写法，没有任何实际收益，反而会引入潜在问题。

只有当你的组件存在以下明确需求时，把props值初始化到state中才有实际意义：

• 需要基于传入的prop生成本地可修改的独立副本：比如表单输入组件接收父组件传入的初始值，后续用户输入修改、临时暂存的逻辑完全在组件内部闭环，不需要每次输入都同步给父组件，只有触发提交等动作时才向外传值。
• 需要阻断父组件更新对本地状态的覆盖：比如弹窗组件接收父组件传入的defaultVisible初始展示属性，当用户手动关闭弹窗后，就算父组件没有同步更新这个prop，也不应该让弹窗自动再次弹出，此时本地维护的visible state就可以脱离父组件prop的更新控制。
• 需要基于传入的原始prop维护本地衍生交互状态：比如父组件传入原始列表数据，组件内部需要独立维护筛选条件、行选中状态、排序规则等强交互相关的状态，这些状态不需要向上同步给父组件，就可以把初始传入的原始数据存为本地state再做后续交互处理。

你当前代码里组件只做number值的纯展示，没有任何本地修改这个值的逻辑，公认最佳实践是直接使用props渲染，不需要额外包裹state，正确写法如下：

export default function Test(props) {
    return(
        <Text>{props.number}</Text>
    )
}

这么写的核心原因有三个：

• 避免状态不一致bug：useState的初始参数仅在组件首次挂载时生效一次，后续父组件更新props.number时，本地的number state不会自动同步更新，页面会一直展示首次挂载时拿到的旧值，这类数据流bug隐蔽性强，排查成本很高。
• 减少无意义的性能损耗：多维护一层无用的state会增加内存占用，还可能触发不必要的重渲染，没有任何正向收益。
• 符合React单向数据流的设计原则：直接使用props的写法更简洁，数据流清晰，其他维护者一眼就能判断这个值由父组件管控、当前组件不对它做修改，降低后续维护成本。

补充：如果确实有合理场景需要把prop存入state，且需要同步父组件后续的prop更新，要手动添加副作用监听同步状态，否则依然会出现数据不同步问题，示例写法如下：

// 仅在确有本地状态维护需求时使用
const [number, setNumber] = useState(props.number);
useEffect(() => {
  setNumber(props.number);
}, [props.number]);

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