从“能用”到“可靠”：React 组件工程中的防御性思维与数据主权

在上一轮关于组件拆分的讨论中，我们回答了“为什么要把 Progress 抽成组件”——那是为了架构上的职责分离与可维护性。只是这一次的代码提交提出了一个更进一层的拷问：组件拆分出来后如何让它从“能显示”进化为“健壮且可靠”？

这次迭代表面上只是给进度条加了个宽度动画、为输入框绑了个状态，但背后触及的。是 React 工程中两个最主要的基石：

1. 数据主权props 和 state 的明确分工。
2. 防御性边界空值合并、类型守卫与人类可读格式化。

一、进度条的重构：把“数据”映射为“视觉"

在早期版本中。Progress 组件仅仅是一个占位符，展示纯文本。本次迭代的主要变动，是让它真正具备了“进度条”的视觉语义。

视觉即状态的观点是，宽度驱动的 UI 映射

{/* 内容 */}

这是一个经典的**轨道-填充**模式：

• 外层容器代表总容量。
• 内层填充块width 属性直接绑定 percentage.

当 {`props.percentage`} 变化时填充块的物理宽度随之变化，使用者就看到了“进度在走”。这种将**业务数据转化为*视觉属性**的过程，正是 React 声明式 UI 的主要魅力——You only change data。UI automatically redraws.

?=，: 组件契约的“守门员”

痛点：父组件有时还未传入完整数据，子组件直接使用会导致白屏或错误。

// 空值合并赋值
percentage?，=;/* 如果 percentage 为 null 或 undefined，则回退到默认值。否则保持原值 */

• 如果你曾因为 props 为 undefined 而 crash，那么这行代码就救你一命。
• 只有当 props 完全缺失时才会触发回退；合法值不会被误伤，
• "封装者多考虑，使用者才用得爽" 是我们设计优雅 API 的准则。

把机器语言翻译成人类语言

{isNaN?"" : `of ${formatBytes}`}

• : 把无感字节数转换为 ~0.95GB。
• #isNaN guard:* 确保 total 非法时不显示 NaNGB。

深层逻辑：* 展示型组件负责渲染结构。同时承担 数据适配器 的角色，将底层原始数据转换为使用者可读展示形态。

二、数据主权：Props 与 State 的分工程序

说到*痛点*。在实际项目里很多人把 state 写到子里却想直接修改父传来的 props，从而导致状态混乱、调试困难。按理说，下面用最朴素 Demo 阐明两者区别。

两者本质定义