分类 JavaScript技术 下的文章

https://interactjs.io/

https://beefree.io/

https://hammerjs.github.io/

https://yabwe.github.io/medium-editor/

https://premiumsoftware.net/cleditor/

https://www.simonewebdesign.it/how-to-make-browser-editor-with-html5-contenteditable/

https://github.com/unlayer/react-email-editor

https://editorjs.io/base-concepts

https://shopify.github.io/draggable/examples/

https://github.com/prevwong/craft.js

https://jsfiddle.net/Twisty/zzv5gdg2/

https://designer.igniteui.com/

https://wiredjs.com/showcase.html

https://ace.c9.io/#nav=about

https://github.com/topics/html-editor

https://cappuccino-cookbook.5apps.com/

https://qooxdoo.org/qxl.demobrowser/#animation~Animation.html

https://github.com/H5-Dooring/dooringx

https://github.com/vanila-io/wireflow

https://www.bootcss.com/p/layoutit/?#

https://muuri.dev/


在涉及到HTML的dom节点操作的时候,使用任何的JavaScript框架都不如使用原生JavaScript代码更加容易,最近一直在纠结到底用什么框架好,用框架的目的是减少重复的工作量,如果用框架反而增加了工作量,增加了复杂度,还不如不用框架。通过观察react、vue等框架,它们的重点关注是form表单、表格等的操作,我想要操作的dom节点,并不是form表单这些操作。因此,为了更加高效地操作dom节点,我决定放弃使用任何框架。直接使用原生js来实现。

一、目前模板编辑器的优点

原来的模板编辑器可以实现大部分数据的定制化需求,确实是实现了很多的定制化功能,减少了代码的改动。

二、目前模板编辑器的缺点

这样做会往往在解析的时候,难度就比较大。因为要考虑的场景太多了。举一个例子说明,我们通过模板编辑器实现了一个床头屏的模板,然后,把这个模板发布到床头屏上,这个模板就可以按照床头屏的业务场景进行显示;同样道理,如果用模板编辑器实现了一个门口屏的模板,然后,把这个模板发布到门口屏上的后,这个模板就可以按照门口屏的业务场景进行显示。这里面有一个问题,那就是目前模板编辑器只是对数据进行了定制化,没有对业务进行定制化。这样就造成了,在终端上进行模板解析的时候,需要考虑到很多的业务场景,同时要求这些业务场景不能够互相冲突。例如,在解析床头屏模板的时候,需要保证床头屏的解析不能够影响到门口屏的业务场景。这样就会造成了代码的业务逻辑复杂度增加了很多。如果后期增加更多的业务场景,会让这个模板解析的代码复杂度越来越高;会变得越来越不容易维护。

三、重新设计模板编辑器

重新设计的模板编辑器要能够实现业务与数据同时定制化。如果能够实现这一点,那么模板解析的工作量就会变得更加容易与扩展。例如,以后床头屏的解析不会影响到门口屏的解析。这样做的好处就是降低了代码的复杂度,同时也会变得更加容易维护。

四、定制化业务和数据

目前的模板解析是一个运行环境,但是这个运行环境包括了各个不同的业务场景,数据的定制化就是选择具体的业务场景在终端上进行解析。以后的模板解析要实现业务场景的选择和数据的解析都是通过后台进行定制化。模板解析只是一个简单的解析环境,例如提供基本的类库调用,通用的功能模块等等。总而言之,凡是具有定制化需求的都通过在模板编辑器里面进行定制化改动。

辽公网安备21010602000703号 备案号:冀ICP备2022001219号