Best Practices for Complex Expressions

同学们，我们今天聊一个在实际开发中特别实用的话题——，怎么在复杂模板里写出干净、好维护的表达式，。你在写 Lightning Web Components 模板的时候，经常会遇到一小段 HTML 里夹着不少计算逻辑，比如数据过滤、格式化之类。如果写得太乱，后期自己都看不懂，性能也容易出问题。所以我们有七条黄金法则，一条一条过。 首先，，保持简单，。模板引擎每次重新渲染都会重新执行表达式，所以别把大段多行逻辑直接怼在 HTML 属性里。遇到多行逻辑，请果断放到 JavaScript 的 getter 函数里。Getter 就像一个属性，模板里直接写 `{propertyName}` 就行，这样模板清清爽爽，逻辑全在 JS 文件里，一眼就能看懂。 第二，，复杂计算一定用 getter，。这不光是为了好看，更重要的是好测试。你可以给这个 getter 写单元测试，模拟各种输入，确保返回正确。如果把它写在模板里，几乎没法单独测。 第三，，重用逻辑就抽成 API 模块，。一个工具函数好几个组件都要用？别复制粘贴，把它放到一个独立的 JavaScript 模块里，导出成公共方法。这样改一处，所有组件受益，而且单独测这个模块也很方便。 第四，，测，往狠了测，。特别是边缘情况，你别光测理想数据，空数组、undefined、非法格式都得覆盖。还要注意 HTML 合规性和浏览器兼容性，比如有些特殊字符在模板里要转义，否则渲染会崩。好代码是测出来的。 第五，，别嵌套太深，。如果你的模板里 div 套 div 超过三层，就说明该拆组件了。深层嵌套不仅让代码像千层饼一样难啃，还降低可读性，甚至影响性能。拉平结构，该抽子组件就抽。 第六，，给箭头函数起个好名字，。模板里遍历数组经常用箭头函数，比如 `list.map(item => ...)`。千万别用 `x`、`i` 这种无意义的名字，起个见名知意的变量名，比如 `order => ...`，别人一看就知道你处理的是什么。 第七，，记得引号规则和 HTML 合规，。复杂表达式用在属性里，一定要用引号包起来，简单绑定才不用。另外，模板里如果用到大于、小于号，由于 HTML 的转义规则，在文本节点里你该写 `>` 而不是 `>`，避免被浏览器当成标签解析错。 最后，，监控性能，。因为每次组件重绘，这些表达式都会重新跑一遍。如果你在模板里做了数组的复杂过滤或者大量计算，每次重绘都来一遍，交互一多就会卡。所以遇到重复计算的情况，在 JS 里给它缓存起来，或者只在数据变化时重新算一次。大型数组操作也要小心，先分析一下数据量，实在太大就在 JS 里做分页或者懒加载。 简单总结：模板保持瘦，逻辑放 JS，能测就测，能抽就抽，注意性能。这样写出来的组件，你自己看舒服，同事接手不骂街，用户用着也顺滑。 下次做复杂展示的时候，把这七条翻出来对着看，保证你的代码质量上一个台阶。好了，下课。