[db:标题]

先前我们在选区模块的基础上，通过浏览器的组合事件来实现半受控的输入模式，这是状态同步的重要实现之一。在这里我们要关注于处理浏览器复杂DOM结构默认行为，以及兼容IME输入法的各种输入场景，相当于我们来Case By Case地处理输入法和浏览器兼容的行为。 开源地址: https://github.com/WindRunnerMax/BlockKit 在线编辑: https://windrunnermax.github.io/BlockKit/ 项目笔记: https://github.com/WindRunnerMax/BlockKit/blob/master/NOTE.md 从零实现富文本编辑器系列文章 深感一无所长，准备试着从零开始写个富文本编辑器 从零实现富文本编辑器#2-基于MVC模式的编辑器架构设计 从零实现富文本编辑器#3-基于Delta的线性数据结构模型 从零实现富文本编辑器#4-浏览器选区模型的核心交互策略 从零实现富文本编辑器#5-编辑器选区模型的状态结构表达 从零实现富文本编辑器#6-浏览器选区与编辑器选区模型同步 从零实现富文本编辑器#7-基于组合事件的半受控输入模式 从零实现富文本编辑器#8-浏览器输入模式的非受控DOM行为 概述 在整个编辑器系列最开始的时候，我们就提到了ContentEditable的可控性以及浏览器兼容性问题，特别是结合了React作为视图层的模式下，状态管理以及DOM的行为将变得更不可控，这里回顾一下常见的浏览器的兼容性问题: 在空contenteditable编辑器的情况下，直接按下回车键，在Chrome中的表现是会插入<div><br></div>，而在FireFox(<60)中的表现是会插入<br>，IE中的表现是会插入<p><br></p>。 在有文本的编辑器中，如果在文本中间插入回车例如123|123，在Chrome中的表现内容是123<div>123</div>，而在FireFox中的表现则是会将内容格式化为<div>123</div><div>123</div>。 同样在有文本的编辑器中，如果在文本中间插入回车后再删除回车，例如123|123->123123，在Chrome中的表现内容会恢复原本的123123，而在FireFox中的表现则是会变为<div>123123</div>。 在同时存在两行文本的时候，如果同时选中两行内容再执行("formatBlock", false, "P")命令，在Chrome中的表现是会将两行内容包裹在同个<p>中，而在FireFox中的表现则是会将两行内容分别包裹<p>标签。 ... 由于我们的编辑器输入是依靠浏览器提供的组合事件，自然无法规避相关问题。编辑器设计的视图结构是需要严格控制的，这样我们才能根据一定的规则实现视图与选区模式的同步。依照整体MVC架构的设计，当前编辑器的视图结构设计如下: <div data-block="true" > <div data-node="true"> <span data-leaf="true"><span data-string="true">inline</span></span> <span data-leaf="true"><span data-string="true">inline2</span></span> </div> </div> 那么如果在ContentEdiable输入时导致上述的结构被破坏，我们设计的编辑器同步模式便会出现问题。因此为了解决类似的问题，我们就需要实现脏DOM检查，若是出现破坏性的节点结构，就需要尝试修复DOM结构，甚至需要调度React来重新渲染严格的视图结构。 然而，如果每次输入或者选区变化等时机都进行DOM检查和修复，势必会影响编辑器整体性能或者输入流畅性，并且DOM检查和修复的范围也需要进行限制，否则同样影响性能。因此在这里我们需要对浏览器的输入模式进行归类，针对不同的类型进行不同的DOM检查和修复模式。 行内节点 DOM结构与Model结构的同步在非受控的React组件中变得复杂，这其实也就是部分编辑器选择自绘选区的原因之一，可以以此避免非受控问题。