minapp

重新定义小程序开发 — 框架篇

March 5, 2018

Mora

在 补全篇 中，主要介绍了 minapp 是如何实现各类语言的自动补全的，这一篇主要介绍使用 @minapp/core 开发框架。

小程序开发中，JS 中主要有三大模块：App、Page、Component。 在 @minapp/core 中，用 class 和对应的装饰器函数对它们进行封装了。如： class BaseApp 和 装饰器函数 appily 可以创建出一个小程序的 App。

import {BaseApp, appily} from '@minapp/core'

@appily({/* 这是是配置 */})
class MyApp extends BaseApp {}

同理，BasePage 和 pagily 对应于小程序的 Page； BaseComponent 和 comily 对应于小程序的 Component。 其中，appily、pagily 和 comily 主要是将 class 转化成 object，并调用对应的小程序的全局函数 App，Page 和 Component。 所以，被装饰器装饰过的类，不能再被继承。如，下面的写法是不对的：

@pagily()
class ParentPage extends BasePage {}

// 下面写法错了
// ParentPage 将无法再被继承了，它实际上只是一个微信原生的 Page 函数调用
class ChildPage extends ParentPage {

}

本来只是一个函数的调用，现在确需要写一个类和装饰器两部分，这样写的优势到底在哪里？

  1. 避免暴露全局函数：微信将它的 App()、Page()、Component() 全都暴露在全局中，而 @minapp/core 将它的这些类和装饰器都放在模块中，需要引入才能使用
  2. 利用类的继承原理，可以赋予对应类更多的功能：比如，实现双向绑定就给 Page 和 Component 中注入了不少函数
  3. 装饰器函数可以给使用者个性化定制的机会：可以在装饰器中可以传入 mixins 配置，另外在 @minapp/mobx 中还可以传入 store 及定制监听
  4. 扩展更方便：如 @minapp/mobx 是对 @minapp/core 的一个扩展，它支持全局的数据管理；如果可能，以后可能还会有更多的类似框架，如 @minapp/redux ...
  5. 更好的自动补全：由于是基于 class，所以在编辑器中，可以有更好的自动补全体验

当然这样写也有一个致命的缺点：由于这你写的虽然是个类，但最后这个类会转化成一个 Object， 所有类上的方法都会重新绑定到那个 Object 上，所以在写类上的方法的时候， 有些东西是不能写的，可以参考这里

最后，要说下用 @minapp/core 框架去开发小程序的一个最佳实践：

当你安装了 @minapp/cli 后，用它 minapp init 创建的项目中，都会有一个 src/base 文件夹， 在文件夹类，定义了你自己的基类 MyApp，MyPage，MyComponent，它们分别继承了 @minapp/core 中定义的类；而在实际的页面或组件中，都继承你自己的基类，而不是 @minapp/core 中的基类。

这样写的好处是，你可以轻松的给你的 Page 或 Component 添加一些全局的新功能， 比如，你可以像 @minapp/mobx 中那样，在基类中实现一个你自己的全局状态管理的功能； 另外，如果你是用 TypeScript 写的话，它还可以跨类感知到你定义的这些新功能， 如，在 SomePage 中可以感知到你的 MyApp 中定义的所有方法和属性。

Recent Posts