从流行的编辑器架构聊聊富文本编辑器的困境
Why ContentEditable is Terrible?
现今主流的 Web 富文本编辑器,大多都是基于 contenteditable 开发的,几年前,Medium Editor 的开发者写过一篇著名的博文:Why ContentEditable is Terrible?,当中列举了一些 contenteditable 存在的一些问题:
现今主流的 Web 富文本编辑器,大多都是基于 contenteditable 开发的,几年前,Medium Editor 的开发者写过一篇著名的博文:Why ContentEditable is Terrible?,当中列举了一些 contenteditable 存在的一些问题:
本文是 《使用 RxJS + Redux 管理应用状态》系列第三篇文章,将介绍我们在使用 Redux 时的困惑,如何重新思考 Redux 定下的范式,以及我们能为此做出的努力。返回第一篇:使用 redux-observable 实现组件自治
本系列的文章地址汇总:
本文是 《使用 RxJS + Redux 管理应用状态》系列第二篇文章,将会介绍 redux-observable 的设计哲学和实现思路。返回第一篇:使用 redux-observable 实现组件自治
本系列的文章地址汇总:
如果你了解 RxJs,在响应式编程中,Observable 和 Obsever 是 push 模型,与之对应的,还有一个 pull 模型:
f(): B
):返回一个值。f(x: A): void
):响应式的,当有值产生时,会发出一个事件,并携带上这个值。订阅了该事件的观察者(Observer)将获得反馈。JavaScript 中的 Math.random()
、window.outerHeight
等都是 pull 模型:
const height = window.outerHeight(); |
pull 模型包含两个部分:
在 pull 模型中,数据是 按需索取 的。
再通过 RxJs 看一个 push 模型的例子:
Rx.Observable |
push 模型的组成包含了两个部分:
与 pull 模型不同,观察者 不能主动索取数据 ,而是观察数据源,当数据源有数据时,才可消费和使用。
push 模型有这么一些优点:
Cycle.js 的作者 Andre Staltz 长久以来面对一个问题,Cycle.js 及其推荐使用的响应式编程库 xstream 都是 push 模型的,这让框架的模型和业务代码都受益于 push 模型的优点。但是,实际项目中,我们还是有不少 pull 模型下的需求,Andre Staltz 也开了一个 issue ,讨论如何更好的使用代码描述 pull 模型。
从今年三月份开始,我在前端的学习路径是: