一楼的问题我查一下

二楼的问题先回答下: 原本其实是打包在一起的, 但后来从设计上做了一个变化, 把uploader拆出来了, 出发点基于如下事实及假设:

今天我作为插件作者, 用的是qiniu的图床,于是我在插件里内置了qiniu-uploader的逻辑
但作为插件使用者, 如果平时用的不是qiniu的图床, 你可能会很郁闷, 希望作者支持另一个图床服务X
于是插件里可能就为此增加X-uploader的代码逻辑, 同时,由于不同的图床暴露的API需要配置的参数可能不同, 于是, 在atom的配置项里, 在qiniu的config之外, 还得加上X的config
...
若干迭代后, 这个插件内置了各种uploader, 参数配置页也臃肿不堪(atom目前的render架构,没找到办法能动态的通过下拉选择动态改变option配置项)
即使如此, 仍然有更多没有集成的图床服务...

所以你明白我为什么想把uploader拆出来了吧?
本质上来说, uploader 可以抽象成如下核心逻辑:

插件给uploader一段image的buffer
uploader从插件自己的配置项里拿到用户配置的上传所需的云平台的参数信息
uploader调用云平台的API, 触发上传操作
上传操作结束后, 返回结果(成功则返回线上图片的地址; 失败则返回失败的返回码)

以上步骤, 其实并不复杂, 但各平台实现各有不同
这些完全可以拆出来作为另一个组件
而且配置页正好可以分离开

这样一来, X平台不支持, 写个X-uploader就好了, 只要保证接口一致, 在markdown-assistant一配置就好了, 岂不快哉~

题外话, 视角放在qiniu-uploader这个插件, 其实这个插件实现了上面的过程, 是通过暴露API 的方式给markdown-assistant调用, 所以, 可以认为这个插件并非只提供给markdown-assistant用, 你如果哪天写个别的插件, 想要上传图片到qiniu, 也完全可以调用qiniu-uploader这个插件.

最后, 如果插件的安装和配置体验上确实造成了一些麻烦
我希望未来可以借用atom 插件的一些机制来弥补这种体验上的差距(比如,插件配置页的能力扩展, 可以动态option,可以动态帮用户安装另一个插件等等)
这是后话了, 目前, markdown 着眼服务于geek用户, 上面的麻烦暂时认为是可以克服的.

以上.

无法使用... #3

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions