前言

designable工程是alibaba团队开源的设计器工程，由于官网提供的《表单设计器开发指南》交付的内容太少了，遂做了如下内容补充。

阅读源码前第一步熟悉工程结构，就像看书前最好先了解书的结构和作者的思想一样，熟悉了工程结构就不容易盲人摸象。

同时只有能给别人讲清楚，才说明你真的懂了。

目录结构

  1. .
  2. ├── CHANGELOG.md                                            // 更新日志
  3. ├── README.md                                                    // 工程文档
  4. ├── examples
  5. │   ├── basic                                                    // designable基础工程，没有组件和属性可以配置。
  6. │   ├── multi-workspace                                // 多个展示区的designable
  7. │   ├── sandbox                                                // 对应basic的沙箱工程
  8. │   └── sandbox-multi-workspace                // 对应multi-workspace的沙箱工程
  9. ├── formily
  10. │   ├── antd                                                    // 适配了designable的antd组件库，相当于designable的物料，即左侧“组件区”。
  11. │   ├── next                                                    // 适配了designable的Fusion组件库，相当于designable的物料，即左侧“组件区”。
  12. │   ├── setters                                                // 做右侧“属性设置”的模块
  13. │   └── transformer                                        // 做“TreeNode与Schema格式互转”的模块
  14. ├── jest.config.js
  15. ├── lerna.json                                                // 多包管理lerna的配置文件
  16. ├── package.json                                            // 工程描述
  17. ├── packages                                                    // 被lerna做多包管理的npm包
  18. │   ├── core
  19. │   ├── react
  20. │   ├── react-sandbox
  21. │   ├── react-settings-form
  22. │   └── shared
  23. ├── scripts                                                        // 工程级别的通用js
  24. │   ├── build-style                                        // 发布样式，从src目录下copy到esm和lib目录下。
  25. │   ├── global.ts                                            // 全局变量的配置（目前看来只有下面的jest.base.js在用）
  26. │   ├── jest.base.js                                    // 单元测试工具jest的配置（目前看来工程没有完善单元测试）
  27. │   ├── release                                                // 根据git提交记录，生成工程的修改日志，也就是工程根目录下的CHANGELOG.md文件
  28. │   ├── rollup.base.js                                // 工程使用rollup做构建，类似webpack
  29. │   └── validate-commit-msg.js                // git提交时会执行此js做日志规范检查
  30. ├── tsconfig.build.json                                // 在build时使用的typescript配置
  31. ├── tsconfig.jest.json                                // 用jest时使用的typescript配置
  32. └── tsconfig.json                                            // 开发时使用的typescript配置

文件速览

examples

演示工程文件夹，里面是各种场景的演示工程。

ps：事实上formily文件夹下还有两个演示工程，具体见下文。

basic

designable基础工程，没有组件和属性可以配置。
image.png

multi-workspace

多个展示区的designable，不确定能做什么，或许做弹窗之类的交互可以用。不过知道能做这件，需要用时能想到它就可以了。
image.png

sandbox*

sandbox以及sandbox-multi-workspace分别是前面两个工程的沙箱模式，但是具体是做什么用的，暂不清楚。

formily

要基于formily生态完成designable工程的必备模块，以及相关的演示工程。

antd

适配了designable的antd组件库，相当于designable的物料，即左侧“组件区”。对应npm包@formily/antd。

同时配套了演示工程，可以在当前目录下执行start脚本，看到如下内容。
image.png

next

这里的next其实就是阿里的Fusion组件库。

所以本目录的，其实是适配了designable的Fusion组件库，相当于designable的物料，即左侧“组件区”。对应npm包@formily/next。

同时配套了演示工程，可以在当前目录下执行start脚本，看到如下内容。

另外，我们会发现用antd和Fusion做出来的效果几乎一摸一样，说明designable可以适配各种上层组件库。

image.png

setters

做右侧“属性设置”的模块，对应npm包@designable/formily-setters，前面的antd和next工程都依赖它而实现界面右侧的“属性配置”。

transformer

做“TreeNode与Schema格式互转”的模块，对应npm包@designable/formily-transformer，前面的antd和next工程都依赖它实现“TreeNode与Schema格式互转”。

package.json

通过 package.json 文件可以看到工程依赖、yran的workspaces配置、npm脚本等信息。

script

先贴下代码，方便参考对照：

  1. "scripts": {
  2.     "bootstrap": "lerna bootstrap",
  3.     "clean": "lerna clean",
  4.     "build": "rimraf -rf packages/*/{lib,esm} && lerna run build",
  5.     "build:docs": "dumi build",
  6.     "start": "dumi dev",
  7.     "start:playground": "npm run start:basic",
  8.     "start:basic": "yarn workspace @designable/basic-example start",
  9.     "start:sandbox": "yarn workspace @designable/sandbox-example start",
  10.     "start:multi-workspace": "yarn workspace @designable/multi-workspace-example start",
  11.     "start:sandbox-multi-workspace": "yarn workspace @designable/sandbox-multi-workspace-example start",
  12.     "test": "jest --coverage",
  13.     "test:watch": "jest --watch",
  14.     "test:prod": "jest --coverage --silent",
  15.     "preversion": "npm run build && npm run lint",
  16.     "version": "ts-node scripts/release changelog && git add -A",
  17.     "version:alpha": "lerna version prerelease --preid alpha",
  18.     "version:beta": "lerna version prerelease --preid beta",
  19.     "version:rc": "lerna version prerelease --preid rc",
  20.     "version:patch": "lerna version patch",
  21.     "version:minor": "lerna version minor",
  22.     "version:preminor": "lerna version preminor --preid beta",
  23.     "version:major": "lerna version major",
  24.     "release:github": "ts-node scripts/release release",
  25.     "release:force": "lerna publish from-package --yes",
  26.     "prelease:force": "lerna publish from-package --yes --dist-tag next",
  27.     "release": "lerna publish",
  28.     "prelease": "lerna publish --dist-tag next",
  29.     "lint": "eslint --ext .ts,.tsx,.js  --fix",
  30.     "postinstall": "opencollective-postinstall"
  31. }

然后逐一解释：

  • bootstrap给被lerna管理的npm包，也就是packages目录里几个工程，一次性安装各自的依赖。
  • clean与bootstrap相反，清理各工程的node_modules。
  • buildbuild出被lerna管理的npm包的结果，放在各自的lib和esm目录下，分别是对应cjs和esm两种格式。
  • build:docs生成工程主页，构建结果在工程根目录的dist文件夹里。（建议对照下面的start阅读）
  • start运行工程本身，也就是工程主页。它是基于dumi制作的，内容就是README.md的内容。
  • start:*这里的*对应examples文件夹下的4个工程，使用这个命令可以快速运行这4个演示工程。
  • test*目前的test脚本似乎并没有相关的代码，仅体现了可以用jest做单元测试
  • preversion发版前运行一下这个脚本可以触发各依赖包的build和eslint检查。因为是pre开头，所以它会在执行下面的npm run version前先触发。
  • version根据git提交记录，生成工程的修改日志，也就是工程根目录下的CHANGELOG.md文件
  • version:*对各个模块进行版本迭代。具体来说是，标识出在上一个 tag 版本以来更新的 monorepo package，然后为这些包 prompt 出版本，在用户完成选择之后修改相关包的版本信息并且将相关的变动 commit 然后打上 tag 推送到 git remote。本质上是为一些发生变动的包进行了一个 bump version 的操作。
  • release*还有prelease都是发版相关脚本
  • linteslint代码检查以及fix。
  • opencollective-postinstall运行本脚本会看到工程的众筹信息，但是package.json中并没有配置collective字段，因此暂无内容。

workspaces

由此可知，开发者主要是用yarn进行包管理，管理了如下三个workspaces。

  1. "workspaces": [
  2.   "packages/*",
  3.   "formily/*",
  4.   "examples/*"
  5. ]

lint-staged

因为安装了lint-staged模块，因此可以配合ghooks，在git commit时触发lint-staged字段里的配置。

  1. "lint-staged": {
  2.     "*.{ts,tsx,js}": [
  3.       "eslint --ext .ts,.tsx,.js --fix",
  4.       "pretty-quick --staged",
  5.       "git add"
  6.     ],
  7.     "*.md": [
  8.       "pretty-quick --staged",
  9.       "git add"
  10.     ]
  11. }

具体来说，会对ts、js以及tsx文件，进行eslint格式校验与修复，并配合pretty-quick完成代码风格调整，如果都没有问题会对修复和调整后的代码做git add。（对md文件除了不做eslint检查，其它都是一样。）

config

  1. "config": {
  2.     "ghooks": {
  3.       "pre-commit": "lint-staged",
  4.       "commit-msg": "node ./scripts/validate-commit-msg.js"
  5.     },
  6.     "commitizen": {
  7.       "path": "./node_modules/cz-conventional-changelog"
  8.     }
  9. }

这里做了两个配置，分别对应ghooks和cz-conventional-changelog模块。

  • ghooks开启了git hook，使用git的commit命令时会触发前面lint-staged字段配置的规则，以及通过scripts/validate-commit-msg.js对提交日志规范做检查。
  • cz-conventional-changelog配合使用npm install -g commitizen全局安装的commitizen可以很方便的创建符合提交规范的日志（如下图）。

image.png