文档: http://china-wesley.github.io/formSchema
github: https://github.com/China-Wesley/el-form-schema
该库的想法来自于http://www.markplayable.com/，是我第一家实习的公司内部使用的。其实也有github https://github.com/shunjinchan/el-schema-form。借鉴了一些设计的思想。在此感谢。（除夕写到12点，尽力了）
开发流程
1、将el-form所有属性，事件，方法全部过一遍
2、开始梳理schema核心数据结构，一次性列出所有的配置是不可能的，列出核心逻辑。剩下的配置在开发中填补。
3、写bug（手动滑稽）
4、编写文档，使用vuepress
难点
-
映射model的结构比较困难，如果是单纯的平面对象，其实封装起来，就比较简单了。无非是将配置统一拿来处理。但是有层级的
model情况就比较复杂，需要考虑object、array类型。为了映射层级关系，Item组件是递归渲染的，并且model也是会逐步的递归传递，但传递到最后Field组件中，要给如input绑定上v-model的时候，Field组件获取到的只是对应字段的值。一个基础数据类型，相当于值能够被传递到Field组件中，但这导致对该值的修改，是无法响应到model对象的，他们本身不在一块内存中
处理： 采取的方法是，在嵌套的结构渲染时，对每个form item的prop进行处理。对象的路径以字符串形式体现出来
model.item[0]。之后用正则对路径进行解析，这样，我可以知道被传递到Field组件中的值，在model对象中，处于什么位置
model：并不是返回属性本身(也就是说，
Field拿到的不再是值本身)，而是返回其父级对象(好比model.home.address这样一个结构，Field拿到的targetModel是model.home这个对象，targetProp是address这个字段，最后在v-model时，通过targetModel[targetProp]，索引到想要的model值，这样可以利用引用数据类型同一块内存的特性，因为tagetModel的内存是全局model对象的一部分，即model.home的内存，是model内存的一部分，model.home中属性的改变，model是能获取到的)
好处：上述这么做的好处，是model是以对象形式传入，无需在意model能不能响应，（传统的做法，可能model是computed的时候就不能响应了，需要在计算属性中增加
get、set），只要内存是同一块，就可以响应得到
-
获取item的ref，或者field的ref
其实与难点一同理，只要能解析出路径，就可以很好的获取。最后要使用路径信息，重建整个model对象的结构，但是这个model对象的每个值，都是对应的ref对象。只是保留了层级结构而已。其实可以直接deepClone一个model，然后通过lodash.set，以路径去改变这个clone的model对象，把他的值全部变为ref。这样，调用getRef方法时，传入的字段，属于哪条路径（可以是多条），就会返回对应的ref
-
需要考虑得很全面，尽量留出自由度，要全面兼容element的配置
其实这一点就是慢工出细活，逻辑上没有很难得地方，但是代码要优雅，要相到使用场景的方方面面也比较困难的。以后慢慢迭代优化吧
待优化
- 样式部分基本没有多写，因为我也不懂要怎么写哈哈哈。这需要结合不同公司的风格，所以我也不好写太多。将自由度留给开发者。但可能有些元素结构的设计，又不太好加样式。所以这一部分待优化。
- 可以增加更多的配置，在未来，我觉得目前的配置虽然够用。但是并没有很让人称赞的地方，尽可能多的减少开发和维护成本，是终极目的。所以在未来的使用中，可能会简化配置项，尽可能多的自动化，自由度和效率是成反比的，自由度越高，需要配置，需要考虑的就越多。所以找到一个平衡点是很重要的。希望在之后的开发中，能够有更多更好的想法。主要还是项目经验比较少。
- 由于model用的是同一块内存，所以使用者如果改变了这个model对象的话，会造成表单元素无法与model一一对应，所以原则上，使用的时候不改model，model初始化定义好之后就不动了，但应该做个报错机制的，之后有空写吧哈哈哈
总的来说
作为自己开发的第一个库，总体来说还是收获颇丰。了解了一个库的设计模式，增强了源码的阅读能力，以及脚手架的搭建能力。更多地熟悉和了解了vue、element，以及ts、嗷，还有lodash。
