团队使用的技术主要是React，用的也是ProComponents组件进行开发，在日常的开发中，增删改查这一类的功能很简单。那么其实编辑和新增的渲染的表单columns是一样的。
所以在这过程中，主包决定偷个懒，把这个表单弹窗封成一个组件，减少写两次BetaSchemaForm。
好嘛，在这过程中就出现了一个小插曲。
BetaSchemaForm在点击编辑之后，在去点击新建的时候，新建的Context区域不再渲染Columns。
那么很容易想到一个属性：forceRender
强制渲染谁不会呀，于是主包的modalProps里面的内容变成了
modalProps:{{width:600,destoreyOnClose:true,forceRender:true}}
好啦，如愿的能够兼容新增和编辑啦，uu也是心满意足了
你以为这就结束啦？
这才刚开始，因为根据团队的规范，在打开编辑的时候，调取了详情接口获取本行的数据，所以使用到了destoryOnClose，关闭销毁，在每次打开弹窗的时候，重新request请求。
这也是问题所在，因为使用到了forceRender所以导致组件初始化挂载，主包在ProTable里面的20条数据的编辑，在初始化的时候都一次性请求。
在同一时间全部请求，这会造成什么问题，大家都清楚吧？这还不包括detail请求，要是columns的select配置了request请求，也会在初始化的一次性全部请求。
正常的话，应该是打开一次，detail request请求一次接口，拿到一次数据。
主包也是没招了，决定舍弃forceRender,自己做强制渲染呗。
于是自己在BetaSchemaForm上，写了一个key去强制渲染。
这又回到了刚开始的，我点击编辑的时候，我此时的key已经强制渲染了一次，那我在表单内容做改变，但是不onFinish，然后在打开新增，新增又渲染不出来了。
经过主包的不断努力，主包发现在表单项发生改变的时候，会导致这个组件再次刷新，所以当前的这个key已经刷新了，导致添加记录的columns项渲染不出来了。
后面又用了时间戳做key，表单项内容改变的时候，直接关闭弹窗。
好了，说了这么多。
说一下主包比较low的解决方法。
主包是把modalProps抽出去了,在使用这个组件的时候，传递modalProps
新增的时候:modalProps:{{width:500,forceRender:true}}
编辑的时候:modalProps:{{width:500,destoryOnClose:true}}
还是把forceRender给拿回来了，浅浅的解决了，等待主包发现更高级一点的写法吧。
