json2html
再这样下去，我感觉我要被离职了。真的，不是我吹牛：“就在昨天（2023年6月6日），我用了几个小时撸了不到100行的代码（包含注释换行在内78行）把公司用了4年的渲染引擎实现了，我命名json2html。之前项目大小约434KB，现在4KB，代码量提升108.5倍。 ”
背景
既然有现成的了，为啥还要再搞一套？我从入行的第一天其实就有这样一个观念： 【技术服务于业务】 。如果业务需要，技术理应想方设法支持。恰好最近新项目搭建用到渲染引擎，但由于业务要求的功能定制化比较高，而渲染引擎适用于统一模版，统一定制，这些高定制化的需求暂不支持，所以才有了json2html的开始。
上周四（6月1日）周会，大家对渲染引擎的定位各抒己见，意见都不尽相同。所以上周五和本周一我就一直在思考（并且在备忘录里罗列了大致思路），一个页面需要哪些内容？如何规划？如何兼容？如何提升效率？ 【跟后端伙伴合作的方式都能提升，跟自己人配合的方式当然也得高效】
流程图
接下来配合流程图我来描述下我心目中的渲染引擎。
如果是渲染静态页面 （此静态非彼静态）？ 这里指的是纯展示的页面，没有任何动作跟交互。那么上面的流程可以轻松应对。
如果页面上有action？例如：点击需要发送请求，点击需要弹窗，点击需要跳转等等。这里会在json2Html中去以onClick属性方式传入。为啥不是在组件内引用action库去处理呢？就像大坝一样，肯定是堵在水库上更容易管理控制，如果放流下去，让地下的小河去管理，会变的很难。
如果页面上有联动呢？例如：输完手机号，立刻弹出验证码输入框；点击按钮，部分页面元素替换等等。这里考虑在json2Html中去封装formItem，跟action同理。那为啥联动要放组件内去处理？之前的渲染引擎可是放在解析器（类比json2Html）处理的。这依赖于我对联动的认知，一方面，我认为联动控制的是当前组件的状态，而这种控制是不做任何限制的。就像组件里面你永远不确定要定义什么state一样。另一方面，当状态变化时，受影响的应该始终只有那些配置了cascade的组件。
后续
目前除了联动以外其他都已完成，由于联动需要牵涉组件库，刚好我的新框架是个新项目，所以可以拿来实验。
哎，木秀于林，风必摧之。像我这样优秀的人，如果真把这套功能搞粗来，估计之前用渲染引擎的人会打我。关键不仅仅是同组伙伴要打我这一个威胁；系统粗来后，大家伙开发效率提高，公司人力资源过剩，到时候要裁员咋办？眼瞅再过十几年就要奔35了，这个风险太大了，扛不住啊。。。
该死的技术控，可恶的自尊心。哎，像我这样优秀的人，太难了。
