写几点小建议

废话不多说，直接开门见山

## Renderer 按需加载 `src/renderers`

内置的 Renderer 的有几十上百个，但是可能实际项目用到的只有一小部分，按需加载可以让项目更轻量，使用场景也更广泛，renderer 可以考虑单独发版。

## 更完备的 Component 库 `src/components`

相比较一些完整的 UI 框架，现在这套内置的 components 相对简陋，以至于在自定义稍复杂的 renderer 时，需要引用第三方 UI，这样的话，样式没办法简单的统一起来。另外，现在内置的 component 在细节设计上美感不足，是否有考虑直接使用成熟的第三方 UI 来适配 renderer 呢？或者在 renderer 适配 component 时做的更灵活一点，除了更换主题样式以外，还开放适配第三方 UI，比如 antd、material-ui 等等。

注：第三方适配不是说 register renderer 的意思，而是允许从底层更换组件体系，不只是样式层面的覆盖或修改。

## 文档&例子呈现和维护

配置化的文档，比较喜欢类似 echarts 的这种书写和呈现风格。用 Markdown 来写，最终会将 Markdown 转为一系列 json 文件，文档页面呈现时，从 json 里读取。

- https://github.com/apache/incubator-echarts-doc
- https://echarts.apache.org/zh/option.html#title

amis 也可以借鉴这类思路，把书写文档、例子、生成 json schema、生成页面等等统一起来。

https://houtai.baidu.com/v2/schemas/page.json

除了现在 `docs` 手写的文档，现在这套 json schema 协议也非常赞，除了起到文档作用，也可以用于校验配置，编写时提示，或者用于生成 IDE Helper 都不错，非常利于提高配置效率，相比较别扭的可视化工具，或者去网站上找例子，复制配置，简单有效的 IDE Helper 会更利于平时开发体验。

还有，**是否可以把 json schema 的部分开源出来？** 现在 json schema 好像稍微滞后，而且还有些错误，描述也比较简陋，example 也没有 ref 进来。开源出来，有不足或者错误的时候，大家可以一起 PR。

这段时间在使用 amis 时，编写了一套 PHP 端写配置的思路，结合 Json Schema 转 Renderer PropTypes，生成 PHP Doc ，写配置就有 IDE Helper 了，开发效率大大提升，还可以生成 TypeScript 的，可以用于前端类型提示，但是受限于 json schema 的内容丰富程度，有些细节做不了，所以非常希望能够更及时的更新和同步 json schema，如果内置到 renderers 里就更好了。不一定直接用 json 来编写，也可以用 yaml 或其他更便捷的方式。

## 测试用例

感觉这个部分的细节比较容易被人忽视，一个没有完整测试的框架，总感觉缺了些什么，用起来也有些顾虑。可以从几个部分来讲述：

components 部分倾向于独立出来（这里的独立是从项目里完全独立出来的意思），对于大众开发来说，可能更倾向于用现成第三方 UI 适配，至少允许第三方适配，比如上面提到的 antd 或 material-ui。使用第三方那就不需要单独测试 component 了，只需要在 component2renderer 核心部分加上一些测试。

renderers 也是可以独立发版的，测试也独立，还可以把 json schema 结合进来做配置校验。感觉会是个比较强壮的思路。

## 鸣谢

一直以来，特别热衷于用配置的方式开发，自己也写过 & 用过类似框架，amis 是最对胃口的，而且非常接地气。非常感谢 amis，大大的提升了开发效率。无论 amis 是否是阉割版，能开源就已经很受益了，这段时间也在阅读和学习源码，以上是我这阵子的使用感受和建议，希望可以深入讨论一下。

amis 到现在才 2.8k 的 stars，增长的也比较缓慢，希望未来可以把细节做的更好，stars 再翻几番。

Start by reading the current implementations under src/renderers and src/components, then review the docs and JSON schema mentioned in the issue. The proposal spans renderer packaging, component adaptation, schema maintenance, documentation generation, and tests, so a contributor would first need to narrow it to one agreed deliverable. Done criteria are not defined in the issue.

Written by the indexing model from the issue text.