Anti-Patterns — What NOT to Do

同学们，今天我们来聊聊Lightning Web Components里的五个关键反模式。什么是反模式呢？就是那些看起来好用、但长期会给你惹麻烦的写法。掌握这些，能让你少踩很多坑，代码也更稳定。好，我们一个一个来看。 第一个反模式，是别去样式化基本组件渲染出的HTML。举个例子，你用了Lightning的基本组件，比如按钮，然后你写CSS直接修改它内部生成的div或span标签。这很危险，因为Salesforce可能会随时更新这些内部结构，而且不会提前通知你。就像你照着别人的房子装修，但主人随时可能把墙敲掉，你的工作就全白费了。所以，别碰你不拥有的内部标记。 第二个反模式，是直接重写SLDS类。SLDS是Salesforce的设计系统，它定义了很多样式类。你可能会想覆盖这些类来定制外观，但直接改会引起冲突，未来升级时也可能失效。正确做法是用样式挂钩或自定义类。样式挂钩就像是预留的接口，让你安全地调整样式，而不会破坏底层结构。 第三个反模式，会有点技术细节，但很实用：别用querySelector去做精确的属性字符串匹配。你知道，在模板渲染时，浏览器可能会折叠空白，或者删除空的属性，导致你的选择器匹配不上。比如，你写`div[title="my title"]`，但渲染出可能变成`div[title="my title"]`无空格，或者缺了属性，你的代码就静默失败了。所以，避免这种脆弱的查找方式。 第四个反模式，是依赖CSS范围标记。在LWC里，每个组件样式会自动加上范围属性，比如`data-lwc`。但在API 59.0及以上版本，这些标记会模糊化成lwc-hash这种不可读的字符串。如果你在CSS里硬编码这些标记来写样式，一升级就全乱套了。别指望它们会保持不变。 第五个，是使用重载或!important选择器。我知道，调试时!important看起来能快速解决样式优先问题，但它会制造雪崩效应。一旦用了，后面想覆盖它就得用更多!important，样式表就变成了蜘蛛网，很难维护。所以，谨慎使用，尽量靠规范的结构来管理优先级。 好了，说了这么多不该做的，那该怎么做呢？我们有一组支持的方法：第一种，用设计变体，就是通过组件的属性来切换内置样式。第二种，实用程序类，比如SLDS自带的间距、对齐工具类，它们经过测试很可靠。第三种，样式挂钩，也就是CSS自定义属性，你可以安全地改变组件的颜色、尺寸等。第四种，自定义CSS类，结合SLDS类一起用，这样你既利用了基础设计，又有自己的特色。还有，用:Host伪类来样式化组件根元素，以及通过@import或类似方式导入共享样式。核心原则是，永远别依赖你不拥有的组件的内部属性或类，那些是Salesforce的地盘。 记住这些，你的代码就会更健壮，升级也不怕。好了，今天就讲到这里，希望大家在接下来动手时，能避开这些陷阱，写出漂亮的组件。