模仿《一期修》的编辑器概述最近突发奇想，想模仿一期修，做一个新的编辑器。主要原因是3年前的编辑在自动化和动画表现上存在一些缺陷。如果人生不能有遗憾，就应该早点开始。没有选择互动大师，我选择了益气修，主要是因为益气修的技术难度比较低。编辑器的核心部分如果全职开发，估计一个月就能完成。如果你是交互高手，核心部分大概足够你业余时间开发了。核心部分包括拖放、组件生命周期、场景增删改、项目增删改、完善的组件事件通信机制、撤销恢复、动画编辑。有兴趣的朋友可以去github看看。有一个在线演示的地址。项目还在持续开发中，轻拍，勿打脸。拖放的核心原理是不同的编辑器。不管怎样，拖拽的业务逻辑一定要自己写。这是血的教训。两年前，我接手了一家公司的编辑部。该编辑器的核心部分使用了一个开源项目。有性能问题，核心元数据的数据结构也有问题。重构了好几次才适合公司当时的业务。性能优化拖拽，其实难点在于性能处理，尤其是在移动端。如果一个场景有上百个组件，移动端会很痛苦。首先，必须使用事件委托，因为事件有冒泡机制，所以我们可以利用冒泡的原理，给parent添加事件来触发执行效果。这样做的好处当然是提高性能。如果不使用事件委托，那么100个组件，每个组件1个旋转点，8个缩放点，1个移动点，会增加800个mousedown事件。如果使用事件委托，则只需要一个mousedown事件。原理是当用户点击页面时，事件中有一个target属性，即用户点击的元素，通过元素的class判断是否为触发点（triggerpoint是移动点、旋转点、缩放点的统称），如果不是，则找到元素的父节点，继续判断是否是触发点，以此类推。继续找文档，如果没有找到触发点，那就点击空白处，找到触发点，找到触发点所属的组件。通过触发点的类型和按下的组件，可以根据mousemove时的分支进行不同的处理。我稍后补图。完成事件委托后，让我们进行函数节流。主要原因是mousemove是高频事件，频率不应该这么高。伪代码如下：private_debounce:Debounce=newDebounce(50,true);。..this._mouseMoveRecycle=Renderer.addEventListener(document,"mousemove",(event:MouseEvent)=>{if(!isMouseDown){return;}this._debounce.handle(()=>{//处理mousemove的内容});});兼容移动端兼容就是功能的完成，这也是大前端最痛苦的事情。为了兼容移动端，有3个事件：touchstart、touchmove、touchend。网上教程很多，我就不赘述了。需要注意的一点是，在touchend返回的事件中，有些浏览器没有event.pageX。如果要用的话，那就在touchmove里面实时记录下来，用到touchend的时候再用。如果哪天你领导说手机移动端可以旋转，旋转之后，editor的元件位置就乱了，因为用absolute的时候元件位置不自适应。示意图如下（红框为手机屏幕）：由于看不到，我们根据方向旋转编辑器。变成如下，用户可以继续编辑。666，问题来了，而且是个大问题。旋转之后，整个世界的坐标系都变了。其实就是根据window.orientation转换event.pageX和event.pageY。这部分会在我做移动端的时候加上。就是这样。几乎？因为部分手机浏览器不支持window.orientation，离兼容处理还有一步之遥。没关系，其实手机屏幕旋转的时候会触发resize事件，然后根据屏幕的宽高计算orientation。或者当鼠标按下时，根据屏幕的宽高获取。以下是伪代码：//判断浏览器是否支持window.orientation，如果不支持，使用事件获取window.onresize=function(){window.orientation=(window.innerWidth>window.innerHeight)?“横向纵向”;}github地址：https://github.com/qq38623289...大功告成，如有遗漏，希望做过这方面的大牛们一起讨论。在下一篇文章中，写下这个编辑器中使用的设计模式。
