grid

最好似乎有个叫jqGrid的最强大。
行高不允许不平均，造成不平均的列应该单独放在弹出或右侧的面板中。
过多不允许换行，直接在行内省略。
过高也不允许。
layui有最后列的固定。

如何实现？目前有太多可选方案。别人的实现可能都丑陋。要以实现美观。贴近原生table。

开发grid最好是使用类似react，每次都使用初始逻辑，未来的变化是没有规律的，可能是行交换，可能是列交换，以行为单位或以列为单位的复用、面向对象，似乎都不太好。集中修改核心模型，直接触发布局改变，vue也能做到，但computed关注局部节点怎样变化，而react式重新生成，以核心影响全局。所有的复用都不太科学。
函数不需要重新生成，函数是惰性的，直到调用时才会去访问核心模型改变效果。所以重绘是绑定函数。重绘的依据，与其说是XML，不如说是结构体，每次重绘整个结构体都得重新生成，完全没复用的可能性。结构体或叫做类，因为有相应的函数调用，而函数是定义在类里面的，结果又回到react。最多复用是享元复用。
重新生成有局部的有全局的，局部是内部变化，全局的可能叫导航变化。缓存节点为组件（类似于函数）。而组件系统复杂到不区分局部导航与局部内部变化——切换页面总是要销毁与生成的，什么多窗口复用与手动复用？
react是对人最友好的方案。
局部改变是自身的重新render，不是父组件通知render。集中在一起的叫组件，分散在各处的强耦合呢？分散在各种，但相互影响而同步，是通过闭包同时render自身的数据中心。
过早优化是万恶之源，先用类似react式的局部实现功能，最后再来细分组件与优化（必须改变的），这种优化细分就是模块化，分化后就受到了限制，失去了全能性。是否有复用性？
针对具体需求的优化。
总之使用react，但优化性地，不再关注控制器等了。
父组件不用自身都render了，只是要调用子组件的某个public方法。如果将组件内所有public方法都挂载到render上。
如果要复用资源，将模板初始化与赋值分开。初始化一次，赋值多次。——这又回到了什么地段？不是以核心和核心的渲染来区分？IMGUI式的。改变模型中心，然后根据模型来刷新。像CSS一样，至于生成了多少中间结构体，并不关心。确实又必须生成结构体，渲染层根据结构体来绘图。绘图根据最终结构体，人不是操作最终结构体。人操作DOM，或许扫描DOM这个结构何体来刷新。

列为基本单位或行为基本单位，也许应该拆分成不同模式的几个控件。

vue的写法果然不符合传统的思维模式。react用jsx，字符串模版也许比实体有优化性，但绑定事件回调，局部闭包，还是得实体化，不如jsdom，或者说，jsdom是jsx到js的中间层。
逐步优化，最开始grid全局一个render，grid的初始化参数，任何一个改变都会触发render重新生成。比如增加减少列，任何参数改变，改变任何参数，就是其public的方法。模型外部注入，初始化与动态改变一致。关注使用，而不像react或vue改变模型。全局render增加减少行是不合算的，但又符合更底层imgui依自定义模型绘图。逐步优化，renderRow与renderColumn。renderColum更高阶，row会完全重新生成，而renderRow包含insert/update/delete，以行为单位重新生成。以行为单位而不是格，因为格可能是render受多个键影响。在vue中事实上自动实现了这种优化。
那么打破传统表格，表格只是列的集合，调整列的顺序更容易了，调整行却要通过模型中心通知，像多个影子一样。
像函数积累，react越复杂会越慢。组件内部也会调用render，即是模型。

参数与方法的一致性，即props。如ligerGrid，参数只有数组与固定键的Object，vue的实现也是这样。
IE8不能使用vue，要么把键变成函数，甚至Object变成函数，要么实现自己的电路链语言。这时的jsObject树，又像DOM树。数组是可变的。

电路链式语言仍然跟vue相似，computed是计算的中心，可能并不关心计算了几次，模型则是入口，像vue可以操作任何一层。