gpt4 book ai didi

slate源码解析(一)-序言

转载 作者:我是一只小鸟 更新时间:2023-02-23 22:31:23 31 4
gpt4 key购买 nike

笔者从大学时期就开始接触的前端,在刚去实习的时候就被导师安排去做内网的一个小富文本工具。之后从毕业后干的第一份工作游戏客户端,到现在做着可视化相关的前端工作,都有在做富文本相关的内容。可以说是和 富文本编辑器(Rich Text Editor) 有着不解之缘.

WYSIWYG

如无特别指出,该系列文章中所说的富文本都是指 WYSIWYG 模式的编辑器。WYSIWYG是英文"What You See Is What You Get"的缩写,翻译过来就是“所见即所得”.

这类产品中最久负盛名的就是Microsoft Word文档。Word文档提供了诸如字体、颜色、背景色、段落等针对文字样式的支持外,还有各种页面排版以及图片、视频插入等富文本功能。并且也完全满足WYSIWYG的原则(除了跨版本打开Word文档时那令人恼火的排版错乱问题).

在Web端更是富文本应用大放异彩的地方。刚提到的Word文档很早之前就有了Web版本,除此之外还有大名鼎鼎Google Docs、前些年很火的笔记工具Notion等。国内近些年也兴起了众多类似模式的Web应用,如主打办公协作的腾讯文档、飞书文档,偏向于知识库管理的语雀等.

不同时代的富文本编辑器

回到开发者的视角;富文本应用可以说是前端中的“天坑”领域了。如果想最快的实现一个简易的富文本,那么只需在给DOM节点增加一个 contenteditable=true 即可让页面变为可编辑的模式。此外还有配套的API- execCommand 可实现在编辑区域内撤销、回退、变更文本样式等功能。这么看来,既然有浏览器的这些支持,那么在Web端实现富文本应该并不是一件很难的事。 但坑就坑在了浏览器的兼容性上。各个浏览器厂商对于 execCommand 支持程度是不同的,为了屏蔽各浏览器的差异而提供一套统一的API给开发者使用,就必须额外地做许多工作。曾经非常著名的CKEditor就是基于该方式实现的.

对于开源界中数量众多的富文本库,个人钟意将其分为两大类:

  • 旧时代的富文本编辑器:代表作CKEditor、TinyMCE、国内百度的UEditor以及众多基于JQuery使用的富文本插件。这些富文本编辑器的最大特点就是“开箱即用”。它们往往都没有太多内置的概念,如果你并没有深入应用的场景,那么遵循官方文档能以非常简单的方式引入便可以在页面中拥有一个可用的富文本编辑器了。并且它们都有预置的极其丰富的各式功能,一般都是在初始化编辑器时以配置的方式传入,以TinyMEC入门文档中的一段代码为例:

    只需在构造函数中传入容器DOM的id和你需要的富文本工具栏的功能集数组,就可以展示出一个完备的富文本编辑器出来了。 而该类型编辑器的缺点非常明显:(1) 能够支持的功能局限在库本身所提供的功能集,可自定义的程度很低。(2) 没有做Data Model和View的拆分,对于编辑器内容的存储和导出往往是与HTML标签高度耦合的。虽然这种方式非常便于直接展示富文本内容,但如果想对存储内容做遍历分析或回显调整等操作的话则会存在诸多不便的地方。并且存储内容中包括太多的HTML标签和样式信息会大大增加数据的体积.

  • 现代化的富文本编辑器:本系列文章的主角 - Slate.js以及同样是基于 React 生态的Draft.js都可以称为现代化的富文本编辑器。 但这两者其实更应该叫做 富文本编辑器框架 。与上一代的富文本编辑器不同,Draft.js和Slate.js不提供任何“开箱即用”的功能。它们都实现了将Data Model和View层的拆分。在View这一层,两者都是基于 React 来做内容的自定义渲染。在Data Model层则是有一套框架自己定义的schema格式,在开发过程中主要精力就是关注在这套Data Model上以及从它们到View层的转换。 作为框架,它们没有任何现成可用的富文本功能,仅是提供一系列开发编辑器所需的基础“元件”和最基本的一套操作API。这就导致了相对于上代编辑器有了更高的上手门槛:哪怕是开发一个再简陋的富文本应用,都需要从零开始实现,因此也有着更大的心智负担和更多的代码量.

接下来

既然本系列文章是解析Slate.js的源码,先来看看Slate这个库中有哪些包:

我们开发者最需要的是两个包:

  • slate 数据模型层。Slate最核心的部分,完全使用Typescript编写,包括了Slate数据模型的定义以及用于操作数据的对外接口。数据模型中的许多类型都是可拓展的(extendable),在后续讲解自定义类型的时候还会细说。
  • slate-react 视图层。负责和前端框架React的对接,渲染富文本内容及用户交互的处理。正是由于这种良好的架构,使得开发者除了可以选择直接使用官方的 slate-react 作为视图层,还可以在不同的前端框架下实现自己的视图层, slate-angular 就是一个非常优秀的例子。

至于 slate-history 包,则是用于为编辑器提供撤销回退操作(undo/redo)的插件,不过笔者还并不打算开 slate-history 的坑: ) 该系列文章中主要是专注于 slate 和 slate-react 的源码解析.

笔者从0.62版本开始就开始调研Slate,当时可谓是一把辛酸泪: ( 各种花式Bug和浏览器相关的兼容问题数不胜数;并且出了问题后能搜索到的资料极少,慢慢翻Slate的 issue 板块也不一定能有解决方案,往往最后之只能用非常hack的方式绕过去。 而在该系列文章,笔者打算基于0.82版本的源码作解析。0.82距最新版本很近,这也是笔者正在使用,已经引入生产环境中并稳定运行了的,曾经已知的许多bug和问题都已经得到了解决: ).

小结

本篇并没有什么实际的干货,笔者只是从自己的角度概述了下在Web端上富文本的分代和它们中典型开源库的介绍,另外再提了下Slate下各个包的作用。但不着急,在下一篇我们就会真正进入到源码之中了:) 。

最后此篇关于slate源码解析(一)-序言的文章就讲到这里了,如果你想了解更多关于slate源码解析(一)-序言的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

31 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com