Open-WC Scoped Elements v3 在 Lion 项目中的渲染问题解析

问题背景

在将 Lion UI 组件库从 Open-WC Scoped Elements v2 升级到 v3 版本的过程中，开发团队发现了一个关键的渲染问题。当页面中同时包含 lion-listbox 和 lion-select-rich 两个组件时，如果 lion-listbox 先于 lion-select-rich 渲染，后者将无法正常显示。

问题现象

具体表现为：

1. 当 lion-listbox 组件先渲染，lion-select-rich 组件后渲染时，后者完全无法渲染
2. 调试发现 lion-select-rich 使用了与 lion-listbox 相同的自定义元素注册表(registry)
3. 如果渲染顺序反过来(lion-select-rich 先渲染)，则一切正常

技术分析

问题的根源在于 Scoped Elements v3 版本中注册表创建逻辑的变化。在 v2 版本中，创建新注册表的条件判断较为复杂：

const shouldCreateRegistry = 
  !this.registry ||
  (this.registry === this.constructor.__registry && 
   !Object.prototype.hasOwnProperty.call(this.constructor, '__registry'));

而在 v3 版本中，这个判断被简化为：

const shouldCreateRegistry = !this.registry

这种简化导致了注册表共享的问题。当第一个组件(lion-listbox)创建注册表后，第二个组件(lion-select-rich)会错误地重用同一个注册表，而不是创建自己的独立注册表。

影响范围

这个问题特别影响以下场景：

1. 使用多个 Lion UI 组件的复杂表单
2. 组件之间存在依赖关系但需要独立作用域的情况
3. 动态加载组件的应用

解决方案

修复方案是将 v2 版本中更全面的注册表创建条件判断重新引入 v3 版本。这个判断确保了：

1. 当没有注册表时创建新注册表
2. 当注册表是继承自原型链而非组件自身拥有时创建新注册表
3. 防止不恰当的注册表共享

技术实现细节

在底层实现上，这个修复确保了每个组件实例都能获得真正独立的注册表，而不是意外共享父类的注册表。这是 Web Components 作用域隔离的关键保证。

最佳实践建议

对于使用 Scoped Elements 的开发者，建议：

1. 在升级版本时特别注意组件间的相互作用
2. 测试不同组件渲染顺序的场景
3. 关注自定义元素注册表的隔离情况
4. 对于复杂的组件组合，考虑增加注册表隔离的测试用例

总结

这个问题展示了 Web Components 作用域隔离的重要性，也提醒我们在进行版本升级时需要仔细评估看似简单的逻辑变更可能带来的深远影响。通过恢复更严格的注册表创建条件判断，确保了组件间的正确隔离和独立运行。