大部分组件的可配置项无非就样式、链接、事件、文案这几种，我们将它们抽离成一个config对象，通过props的方式传递给子组件用于渲染样式或者加一些点击事件等，比如bind绑定传进来的style样式，当然在这之前一定要定好基础config的规范。
渲染函数
由于一些业务的原因，Lego除基础组件外其它部分开放的自由度并不算高，所以props的方案目前可以满足我们的需求，但如果你想开放更高的自由度，释放系统的完全编程能力，比如配置一些点击事件，事件执行交互等等。那可以试试Render渲染函数。根据官网对它的描述，它比模板要更接近编译器。而它的可配置对象足够你肆意发挥了。
布局方案
可视化布局的方案抛开大厂不谈，根据公司人员配比，建议大部分中小公司只需要以下两种方案的一种即可。根据不同的优缺点来选择最适合你的方案，如果条件允许也可以二者结合实现。
抽屉式自上而下顺序排列，可以更换组件位置，但不能实现元素定位，没有层级概念，遇到复杂布局或者需要叠放元素时不够灵活，如果需要实现复杂页面的效果则需要引入复合UI组件的概念，它需要大量现成的UI组件。优点是将可操作程度限定在了一个可控的范围内，对非设计人员来说只需要通过现有UI组件进行拼装即可生成一个美观度较高的页面，lego即采用的是此方案。
自由式
完全可随意拖拽元素位置，自由度高，只需几个基础UI组件即可，存在层级概念，可任意叠放拼装，在无成品UI组件的情况下diy出复杂页面。但页面不可控，对操作人员的美感要求更高。更适合UI同学操作使用。下图只是一个复杂布局的例子，关注布局即可先不要管业务逻辑如何实现。
关于自由度
结合布局方案聊一下关于可编辑自由度的问题，编辑自由度应该综合实际情况进行考量。
对于lego而言，UI同学仅参与组件设计的工作而不会去使用此系统去编辑发布活动，而当UI同学不直接参与最后的拼装上线时，高自由度的编辑操作对我们而言其实是个鸡肋，直接开放高自由度给运营人员，由于存在层级叠放且可自由拖拽，这样就会有可能面临着大量的不可控的页面样式，即使在编辑完后UI同学对页面效果把关，但相较于改起来的时间成本和活动质量来说是得不偿失的。而且高自由度带来的是更多的技术的考量和实现成本，嵌套组件的层级规则、拖拽方案、组件定位等等….所以当你的团队技术实力和你能得到支持的资源不是那么充分时，也许抽屉式的半自由度方案更加适合你。
半自由度从布局方案到组件的可配置项上来说开放程度有限，组件方面针对基础UI组件开放相对高的配置编辑项，同时积累大量的成品UI组件可选。在编辑时不需要考虑太细节的样式问题，保证页面质量。
当开发人力和资源和部门协同、工作流程都到位且规范的情况下，两种方式结合其实是最佳的方案。可以提供不同模式来供不同人员使用，甚至可以实现在线编辑器来供研发人员直接进行代码调整。
组件分类Lego将组件分为了两大类：UI组件、业务组件
UI组件细分为基础组件和复合组件，UI组件仅用来做静态展示用。原则是自身不包含任何业务逻辑，由于采用半开放的布局方案，对于复杂样式来说我们又基于基础组件封装了很多不同功能不同用处的复合型UI组件用以满足更复杂页面的需求。比如不同主题的标题、按钮、都可以单独封装出来直接用于拼装。
业务组件是指那些和服务端有交互的有业务逻辑在里的组件，属于独立的功能模块，可以理解成每个业务组件都是一个单独的活动，比如购卡、抽奖、分享等等。lego针对业务组件的唯一原则就是不在系统内提供业务相关可配置入口，仅开放基础样式配置，如大小、主题色等。将权限回收至研发手中，每个业务组件在营销后台中配置数据，通过不同活动id进行区分渲染。因为每个业务组件发布前都经过了QA的完整测试流程，可以最大程度保证活动的稳定性，而不至于影响到业务。
配置项