Base Component Composition — Flat Structure

同学们，咱们今天聊一个Lightning Web Components里关于组件设计的小技巧，叫做，扁平结构，。听起来有点抽象对吧？别担心，我慢慢给你解释。 想象一下，我们平时搭建界面，习惯用“合成”的方式：就是在一个父组件里，直接把子组件的标签写在模板里，一层套一层。就像搭积木，一个父组件管着一大堆小积木（子组件），每个子组件自己再负责渲染。这种方式很清晰，代码读起来也直观，所以大多数时候都是首选的。 但有时候呢，我们遇到数据量特别大的情况，比如一个超长的列表、一个几千行的表格，你会发现页面开始卡顿了。这时候我们就需要考虑一种替代方案，也就是“扁平结构”。它不是说组件本身变扁了，而是设计思路上变“扁平”了。 在扁平结构里，我们不直接在模板里写一大堆子组件标签了。而是，通过属性（比如 options、data、items、columns 这种名字），把配置数据传进去。然后这个基本组件内部靠自己来管理所有子元素的渲染，它会直接生成大量的原生 HTML 元素。 咱们熟悉的 `lightning-select`、`lightning-combobox`、`lightning-datatable` 还有 `lightning-map`，这种复杂组件就是典型的扁平结构。你看，我们用 `lightning-datatable` 的时候，不就是在父组件里传给它 `columns` 和 `data` 两个属性就完事了吗？它背后噼里啪啦帮你生成好多原生的 ``、``、`

`，你一个子组件标签都没写。 那它有什么好处呢？，性能！， 原生 HTML 内联渲染比创建成百上千个自定义组件实例要快得多，内存占用也少。而且这么做，组件作者（就是 Salesforce 团队）能对每一个细节的渲染和验证做更细致的控制，保证底层运行高效又安全。 那问题来了，为什么我们不所有地方都用扁平结构呢？凡事都有权衡嘛。扁平结构的缺点是，可读性和可维护性会变差，。如果你自己写了一个扁平结构的组件，里面全是以数据驱动的方式生成 HTML，别人（包括三个月后的你自己）看这段代码，可能一头雾水，不如看标签嵌套的合成结构那么一目了然。所以一般情况下，我们还是优先用传统的合成方式，它让代码更友好。 最后，老师给你一条性能指导：如果你发现自己的应用里，有特别多层的嵌套合成，结果界面反应慢，该怎么办？可以试试，扁平化，这个思路。怎么做呢？把一些逻辑往上提到父组件，尽可能把子组件里能改成原生 HTML 的地方直接内联掉，减少那些最底层的叶子组件里自定义元素的实例数量、事件处理程序的数量，以及避免不必要的重新渲染。说白了，就是把那些频繁创建、销毁的自定义元素，换成静态一点的原生元素，用父组件的逻辑去驱动，这样能大大提升大型数据场景下的性能。 好，今天就讲到这儿。记住：合成优雅易懂，扁平强悍高效，按需选择，关注数据量，你就能写出又快又漂亮的组件了。下课！ 关键词 LWC Lightning Web Components Salesforce 返回课程章节列表