在 react 中直接操作 dom 禁用动态渲染的 `
React 的核心原则是声明式 UI与单向数据流：组件行为应由 props 和 state 驱动，而非手动修改 DOM。你在 componentDidUpdate 中使用 document.querySelectorAll 并设置 btn.disabled = true，看似生效，实则存在严重隐患：
- ✅ 原生 disabled 属性会被浏览器识别（按钮视觉变灰、不可点击）；
- ❌ 但 React 下次重渲染时，若 ShowForm 组件内部未将 disabled 状态纳入其 JSX 输出逻辑（例如未绑定 disabled={isDisabled}），React 会根据虚拟 DOM 差异重新“恢复”原始状态，覆盖你手动设置的 disabled 属性 —— 这正是你“无法持续禁用”的根本原因。
✅ 推荐方案：从数据源头控制（最佳实践）
修改 JSON 数据结构，在传入 ShowForm 前注入禁用逻辑：
componentDidUpdate(prevProps, prevState) {
// 仅在表单数据更新后处理
if (prevState.data !== this.state.data) {
const updatedData = {
...this.state.data,
buttons: (this.state.data.buttons || []).map(btn => ({
...btn,
type: 'submit',
disabled: true, // 显式标记为禁用
label: 'PREVIEW'
}))
};
// 注意：需确保 ShowForm 能读取并应用该 disabled 字段
this.setState({ data: updatedData });
}
}并在 ShowForm 内部渲染时消费该状态：
// ShowForm.js 示例片段
function ShowForm({ src }) {
return (
<form>
{src.buttons?.map((btn, idx) => (
<button
key={idx}
type={btn.type}
disabled={btn.disabled} // ✅ 由数据驱动，稳定可靠
className="btn btn-warning btn-md"
>
{btn.label}
</button>
))}
</form>
);
}⚠️ 替代方案：CSS 层面禁用交互（仅限快速验证）
若暂无法改造组件逻辑，可用 pointer-events: none + opacity 模拟禁用效果（注意：不阻止键盘提交或表单自动提交）：
componentDidUpdate() {
document.querySelectorAll('button[type="submit"]').forEach(btn => {
btn.textContent = 'PREVIEW';
btn.style.pointerEvents = 'none';
btn.style.opacity = '0.6';
btn.style.cursor = 'not-allowed';
});
}? 重要提醒：此方式仅阻断鼠标事件，用户仍可通过 Enter 键触发表单提交。生产环境严禁单独依赖此方案。
? 不推荐：Web Components 或直接 DOM 操作
官方文档虽提及 Web Components 集成，但它适用于封装跨框架可复用组件，并非解决禁用问题的合理路径；而绕过 React 直接操作 DOM（如 btn.disabled = true）违背其设计哲学，易引发状态撕裂、内存泄漏及 SSR 不兼容等问题。
✅ 总结
| 方案 | 可靠性 | 可维护性 | 是否推荐 |
|---|---|---|---|
| 数据驱动 disabled 属性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ✅ 强烈推荐 |
| pointer-events: none + 样式 | ⭐⭐ | ⭐⭐ | ❌ 仅调试/临时使用 |
| 原生 DOM disabled = true | ⭐ | ⭐ | ❌ 易被 React 覆盖，应避免 |
始终让 UI 状态成为 state 或 props 的纯函数输出——这是写出健壮、可预测 React 应用的关键。
