Dan 表示,目前 React DOM 存在着相当多的已知问题,如果没有更大的内部变化,其中一些问题很难或根本无法修复,这些问题导致了无数的后续修复工作并产生了大量的技术债务。在这项被称为 React Fire 的现代化 Reat DOM 改造计划中,开发团队希望删除事件系统中的一些抽象,这些抽象从 React 诞生以后就几乎没有被触及,并且是系统复杂性和项目包变大的根源。
Dan 详细介绍了目前关于 React Fire 的一些想法:
停止在 value 属性中映射输入值。这最初在 React 15.2.0 中被添加,它是一个非常普遍的要求,因为人们对 DOM 的概念模型是他们在 DOM 检查器中看到的值应该与 JSX 的属性匹配。但这并不是 DOM 的工作方式。当你在键入字段时,浏览器不会更新 value 属性,那么 React 也不应该这样做。事实证明,这种变化虽然可能对依赖 CSS 选择器的一些代码有所帮助,但却引发了一系列 bug,其中一些仍未得到修复。
在 React 根目录而不是 document 对象中添加事件。将 React 应用程序嵌入到更大的系统中时,将事件处理程序添加到 document 对象会成为一个问题。Atom 编辑器是最早遇到这种情况的案例之一。任何大型网站最终也会发展出与 stopPropagation 相关的非常复杂的边缘案例,它们与非 React 代码或跨 React 进行交互。
从 onChange 迁移到 onInput,并且不要填充不受控制的组件。React 在 DOM 中使用不同的事件名称来表示输入事件这让人十分困惑。虽然我们通常避免在没有显著优势的情况下进行这样的大改动,但在这种情况下,还是希望去消除一些复杂性,这些复杂性仅对改变控制输入等边缘情况是必需的。因此,将这两个更改结合在一起是有意义的,并将其用作为一种 onInput 和 onChange 完全按照 DOM 事件对不受控制的组件执行的操作的尝试。
大大简化事件系统。自 2013 年实现以来,当前事件系统几乎没有变化。它在 React DOM 和 React Native 中被重复使用,因此它是不必要的抽象。它提供的许多 polyfills 对于现代浏览器来说是不必要的,并且其中一些会产生比他们解决的问题更多的问题。它也占据 React DOM 包的很大一部分。关于这一点,目前还没有非常具体的计划,但是可能会完全将事件系统再 fork 一份出来,然后看看在更接近 DOM 赋予的东西的时候可以去做些什么。而完全摆脱冒泡事件似乎是合理的。应该停止冒泡活动,比如媒体事件,这些事件不会在 DOM 中冒泡,也没有充分的理由冒泡。
className → class。这已经被提出了无数次。目前已经允许在 React 16 中将 class 传递到 DOM 节点中,这样做导致的混乱实际上是比语法限制来得有意义的。
Dan 还表示,为了达成此目标,可能需要降低与某些旧浏览器的兼容性,并且可能需要更多独立的 polyfill,详情可以查看原文进行了解。
对于这个 issue,你是怎么看待的呢?欢迎在评论中留下你的想法。