Closed nihaojob closed 6 months ago
我遇到的麻烦
我目前可以根据这套规则来实现插件化架构,但是不确定要不要引入 tapable,如果用从基础的发布订阅来看,events可以满足我们大部分场景的需求。
但是只有1个功能无法满足,例如 我们希望通过插件机制来实现自动加载字体, 插入JSON前,字体插件会JSON遍历出字体并进行加载,并阻塞钩子的进程,等字体文件加载完成后,再执行其他的钩子事件。
events并没有提供这样的功能,而且 tapable 的AsyncHook可以更容易的实现,但是引入 tapable 可能会增加大家的理解成本。
我遇到的麻烦
我目前可以根据这套规则来实现插件化架构,但是不确定要不要引入 tapable,如果用从基础的发布订阅来看,events可以满足我们大部分场景的需求。
但是只有1个功能无法满足,例如 我们希望通过插件机制来实现自动加载字体, 插入JSON前,字体插件会JSON遍历出字体并进行加载,并阻塞钩子的进程,等字体文件加载完成后,再执行其他的钩子事件。
events并没有提供这样的功能,而且 tapable 的AsyncHook可以更容易的实现,但是引入 tapable 可能会增加大家的理解成本。
还好吧,如果非开发的话,并不关注理解第三方库。比如很多人用vuedraggable,但很多人都不知道他是用了sortable.js。一般这种情况,我考虑的是第三方包的稳定性和大小
我遇到的麻烦
我目前可以根据这套规则来实现插件化架构,但是不确定要不要引入 tapable,如果用从基础的发布订阅来看,events可以满足我们大部分场景的需求。 但是只有1个功能无法满足,例如 我们希望通过插件机制来实现自动加载字体, 插入JSON前,字体插件会JSON遍历出字体并进行加载,并阻塞钩子的进程,等字体文件加载完成后,再执行其他的钩子事件。 events并没有提供这样的功能,而且 tapable 的AsyncHook可以更容易的实现,但是引入 tapable 可能会增加大家的理解成本。
我遇到的麻烦
我目前可以根据这套规则来实现插件化架构,但是不确定要不要引入 tapable,如果用从基础的发布订阅来看,events可以满足我们大部分场景的需求。 但是只有1个功能无法满足,例如 我们希望通过插件机制来实现自动加载字体, 插入JSON前,字体插件会JSON遍历出字体并进行加载,并阻塞钩子的进程,等字体文件加载完成后,再执行其他的钩子事件。 events并没有提供这样的功能,而且 tapable 的AsyncHook可以更容易的实现,但是引入 tapable 可能会增加大家的理解成本。
还好吧,如果非开发的话,并不关注理解第三方库。比如很多人用vuedraggable,但很多人都不知道他是用了sortable.js。一般这种情况,我考虑的是第三方包的稳定性和大小
Get,谢谢June的讨论。
https://github.com/nihaojob/vue-fabric-editor/commits/refactor-plugin 插件化进展同步 已支持快捷、API、事件相应,已改造对齐线、拖拽功能。
你的插件话,会像 polotno 那样的配置嘛?
能否给Editor插件单独打包?这样方便其他框架或者应用引用
插件化架构思考
为什么要插件,fabric.js已经是一个支持发布订阅,可扩展的canvas library。再基于fabric.js封装一个层插件化架构,是否过度设计的一些辩证思考。
插件功能
插件化应尽可能的简化,便于开发人员快速理解与扩展,但要满足基础的需求:
插件API构想
插件的静态属性:
插件生命周期:
编辑器生命周期:
快捷键扩展事件:
右键菜单扩展事件:
插件伪代码实例
编辑器整体架构
按照插件化重构后,将分层更加清晰,将分为如下几个部分:
模块关系如下图: