2022.04.29
Array.from() // for in for map reduce filter some //
vue 平时用到的优化点
vue 新的 api 包括 3 的优化点是什么
编辑器里面主要是做了啥
编辑器的难点 亮点
我在这个编辑器里面主要是提供了一个挂载点的功能: 让第三方应用能够使用
编辑器遇到的难点
表格做的优化
我用的是 element 的 table 组件 ,因为用户在进来的时候其实更多的是去看,而不是去使用,所以我们在组件层面做了懒加载的处理,比方说用户的 table 有三列(开始时间、结束时间、处理人)时间控件,人民空间,我们会根据 dom 的类型,通过代理的形式把时间或者人名的类型获取到再去挂载相对应的组件,进行替换(里面用到 vnode.el)。
还做了双向懒加载的优化: 我们自定义了用户浏览器的宽高(getBroundClientWidth, height),在首屏进来的时候,因为这个需求树的高度我们是确定的,前端会去获取当前浏览器需要加载的对应的数据,比方说如果这个用户有 200 个需求树,根据用户的浏览器大小 我能获取这个父需求下的前 50 个子需求,我,等到他往下面滚动的时候,采取加载剩下的 150 个子需求。因为我们自己实现了滚动条。可以计算出用户的偏移量,能够知道他的滚动范围,能够计算出相对应应该加载的数据。
ui 控件 = 「100」; 大小 = 【100】;
渲染层面: 每个组件会渲染 10*10;现在只要渲染 10;
vue 和 react 讲对比
为啥 react 要搞 immutable
react 的 shouldComponentUpdate 是怎么实现的
怎么做技术选型,当初为啥选择 tinymce
draft.js 和 slate 都是依赖 react,uEditor 没有在维护了. powerpaste 算是一个亮点
开源可商用
插件丰富, 自动插件基本涵盖日常所需功能
接口丰富,可拓展性强,有能力可以无限拓展功能
api 文档很清晰
首先如果你的业务及其复杂,需要定制很多自定义功能,那么 slate 无疑是首选,但是前提是你要自己去实现 view 层,并且有这个开发能力
基于 DOM API 实现 selection、rang
多人实时协同编辑怎么做
调研对象: google docs, ckeditor 5, slate, quill 结论: 都用 operation transformation,将操作转化为 op,发送到协作服务,在转发给其他在线用户。
我觉得可以改进的部分: 1.增加实时协同的功能 具体实现方案: 引入新的 command 机制,所有的变更都通过 command 完成,变更之后产生对应的 op,包括 backward 你想操作。
{p:PATH, li:NEWVALUE}
List Insert
插入 Node
{p:PATH, ld:OLDVALUE}
List Delete
删除 Node
{p:PATH, oi:NEWVALUE}
Object Insert
增加 Element 属性
{p:PATH, od:OLDVALUE}
Object Delete
删除 Element 属性
前后端分离的好处
提供工作效率,分工更加明确。前端只关注前端的事,后台只关心后台的活,两者开发可以同时进行,在后台还没有时间提供接口的时候,前端可以先将数据写死或者调用本地的 JSON 文件即可,页面的增加和路由的修改也不必再去麻烦后台,开发更加灵活。
2.局部性能提升。通过前端路由的配置,我们可以实现页面的按需加载,无需一开始加载首页便加载网站的所有的资源,服务器也不再需要解析前端页面,在页面交互及用户体验上有所提升。
3.降低维护成本。通过目前主流的前端 MVC 框架,我们可以非常快速的定位及发现问题的所在,客户端的问题不再需要后台人员参与及调试,代码重构及可维护性增强。
4.实现高内聚低耦合,减少后端(应用)服务器的并发/负载压力。
5.即使后端服务暂时超时或者宕机了,前端页面也会正常访问,但无法提供数据。
tinymce 的协同编辑
tinyMCE 遇到的问题
遇到的难点:
最后更新于
这有帮助吗?