可以贡献开源吗？

4. 更多的支持

在编辑器中编辑笔记是html或markdown类型的，笔记组件支持将笔记导出为一个PDF文档。因此，设计时我们可以将组件的一些能力抽象为api，再次扩展组件的api：

方法说明参数exportPDF导出笔记为PDF文件-toggleFullscreen切换全屏显示(value: boolean) 是否全屏展示

组件设计时，我们可以将可预见范围内的组件的能力设计为api，需要注意的，方法的参数与返回值也是api的一部分，应当谨慎设计。

除了扩展组件的能力外，我们还可以扩展组件的视图。注意到阅读按钮右侧的工具栏了吗?我们假设这部分的视图不属于笔记组件，是通过api扩展而渲染出来的，这就是组件的子视图设计，在web前端的组件化中，称为插槽。我们可以为笔记组件扩展一个工具栏的插槽：

插槽说明参数toolbar工具栏子视图{ data }

当调用者想要扩展笔记组件的工具栏时，可以这么使用：
 

在设计api时，我们在满足需求的前提下，支持了更多情况。首先，使用者也可能只使用编辑模式，因为mode参数是支持随意组合各种模式的，因此这种情况也能满足。另外，如果组件以后扩展了更多模式，该api仍然能满足需求，只需要为mode数组增加更多的模式项即可。这里有一个更佳的设计是，当使用多个模式时，确定哪个模式作为初始模式也是有必要的，因此，将mode数组的第一项作为多模式下的初始模式，既满足了需求，又达到了api设计最小化的原则。

现在，我们对用户的需求进行了扩展，不仅支持只使用阅读模式，还支持各种模式任意组合和初始模式，但是这还不够，组件的设计者应当针对需求想到更长远的情况，针对这个例子，我们还可以为组件扩展一个模式改变的事件，让调用者可以捕捉到笔记组件从阅读 -> 编辑或编辑 -> 阅读(随着模式的扩展，这种组合会更多)切换的时机：

事件说明回调参数modeChange模式切换时触发(from: string, to: string) from表示切换前的模式，to表示切换后的模式

调用者可能在捕捉到模式切换事件时，做一些特定的工作：
 

这种架构的优点：

• 服务彻底拆分，各服务独立打包、独立部署和独立升级。
• 每个微服务负责的业务比较清晰，利于后期扩展和维护。
• 微服务之间可以采用REST和RPC协议进行通信。

这种架构的缺点：

• 开发的成本比较高。
• 涉及到各服务的容错性问题。
• 涉及到数据的一致性问题。

（编辑：周口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!