Lit中ReactiveController三种实现模式的合规性与选型问题

下文展示了使用Lit实现ReactiveController的三种不同方式，基于Lit的典型ReactiveController实现写法如Pattern 1所示。

注意：Pattern 2与Pattern 3中未编写implements ReactiveController声明，这是因为ReactiveController接口的所有方法按设计均为可选实现。Pattern 3采用工厂函数创建typeof SomeController类型的对象，该写法的优势在于未来可根据传入参数返回SomeController的不同子类型实例，这是Pattern 1与Pattern 2无法实现的能力。

三种实现代码示例 #

Pattern 1：标准类实现 #

export class SomeController implements ReactiveController {
  // ... 自定义属性、方法

  constructor(host: ReactiveControllerHost, ...) {
    // ... 初始化逻辑
    host.addController(this);
    // ... 其他初始化逻辑
  }
  
  hostConnected() {
    // ... 组件挂载时执行逻辑
  }

  hostDisconnected() {
    // ... 组件卸载时执行逻辑
  }

  // ... 其他自定义方法
}

Pattern 2：内联对象传参实现 #

完全相同的控制器也可通过如下方式实现：

export class SomeController {
  // ... 自定义属性、方法

  constructor(host: ReactiveControllerHost, ....) {
    // ... 初始化逻辑
    host.addController({
      hostConnected() {
        // ... 组件挂载时执行逻辑
      },

      hostDisconnected() {
        // ... 组件卸载时执行逻辑
      }
    });
    // ... 其他初始化逻辑
  }

  // ... 其他自定义方法
}

Pattern 3：工厂函数实现 #

此外，也可使用工厂函数实现：

export function getSomeController(...): typeof SomeController {
  return new SomeController(...);
}

// SomeController类为局部实现，不对外导出
class SomeController {
  // ... 自定义属性、方法

  constructor(host: ReactiveControllerHost, ....) {
    // ... 初始化逻辑    
    host.addController({
      hostConnected() {
        // ... 组件挂载时执行逻辑
      },

      hostDisconnected() {
        // ... 组件卸载时执行逻辑
      }
    });
    // ... 其他初始化逻辑
  }

  // ... 其他自定义方法
}

问题解答 #

1. Pattern 2与Pattern 3的实现方式，是否在某种程度上违背了Lit的ReactiveController模型设计初衷？ #

完全不违背。

• Lit对ReactiveController的设计从一开始就采用鸭子类型规则：接口定义的所有生命周期方法全为可选实现，不强制要求实现类必须写implements ReactiveController声明，也不要求必须用类的形式实现——只要传给addController的对象包含对应生命周期方法，就能被Lit的Host正常识别调用。
• Lit官方本身也支持直接传入纯对象字面量作为轻量控制器，Pattern 2、Pattern 3本质是把生命周期逻辑封装在传入addController的内联对象中，完全符合接口规范，不存在违背设计初衷的问题。

2. 针对Pattern 1的实现：是否存在真实应用场景需要将SomeController实例二次传入addController方法？公开生命周期方法的实际意义是什么？为何不始终使用Pattern 2或Pattern 3？ #

存在大量需要重复传入控制器实例的真实场景：

• 跨组件共享单例控制器：比如全局主题控制器、全局状态订阅控制器、用户权限控制器这类单例依赖，所有用到该能力的组件都会在自身初始化时，把同一个控制器单例传入自身的addController方法完成注册。这种场景下同一个控制器实例会被数十上百个Host组件调用addController注册。
• 动态挂载/卸载控制器：不少业务场景下需要根据组件状态、用户交互动态启停控制器能力：比如表单组件只有在编辑模式下才挂载输入校验控制器，退出编辑模式就调用removeController卸载，这类动态注册的场景也要求控制器实例本身可被重复传入addController。
• 以上两种场景下Pattern 2、Pattern 3完全无法适配：这两种写法传给addController的是构造时生成的临时内联对象，控制器类本身的实例上根本不存在hostConnected/hostDisconnected方法，直接把类实例传给第二个Host的addController时，Host找不到任何生命周期方法，控制器逻辑完全不会触发。

将hostConnected/hostDisconnected设为公开方法，除编码偏好、可读性外的实际价值：

• 支持继承扩展：当需要基于基础控制器派生子类时，子类可以直接重写公开的生命周期方法，在自定义逻辑执行后调用super.hostConnected()复用父类逻辑，如果生命周期方法是闭包在内联对象中的，子类根本无法访问、重写这部分逻辑。
• 降低单元测试成本：测试控制器逻辑时，不需要真实渲染Lit组件作为Host，直接实例化控制器后手动调用公开的生命周期方法，就能模拟组件挂载、卸载的场景完成测试；闭包在内联对象里的生命周期方法对外不可见，无法单独触发，测试成本会高很多。
• 支持控制器内部逻辑复用：不少控制器会对外暴露重置、重连类的方法，内部逻辑就是直接调用自身的hostDisconnected()清理旧订阅、监听，再调用hostConnected()重新建立连接，如果生命周期方法是闭包私有的，类内部的其他方法也无法调用这部分逻辑。

不始终使用Pattern 2/3的核心原因：

Pattern 2、Pattern 3仅适合和单个Host强绑定、不需要复用实例、不需要继承扩展的极简单控制器场景，适用范围非常窄。而Pattern 1的写法让控制器实例本身完全符合ReactiveController接口规范，可以适配所有使用场景，包括单例共享、动态挂载、继承扩展、便捷测试等，是通用场景下的标准实现方案。

内容的提问来源于stack exchange，提问作者Natasha