如果美麗 or 帥氣的你是從 Vue / React 轉過來使用 Lit，大概率會有一個疑問：

狀態放哪？
沒有 store？沒有 hooks？沒有 provide/inject？
這怎麼寫複雜組件？

答案很簡單，也很“反直覺”：

Lit 的設計目標，從一開始就不是“承載複雜狀態”。

而是：

讓組件只關心“輸入 → 輸出”。

一、先給結論（IImportant）

Lit 不缺狀態管理能力，
它是刻意拒絕把狀態管理“內置進組件模型”。

這和 Vue / React 是根本性的設計分歧。

二、Lit 的核心假設是什麼？

Lit 的核心假設只有一句話：

複雜狀態應該存在於組件之外，而不是組件內部。

所以 Lit 的組件更像：

• 純 UI 單元
• 行為可預測
• 輸入輸出清晰

而不是：

• 業務狀態容器
• 數據流中心

三、Lit 的“狀態”到底是什麼？

在 Lit 中，只有一種真正意義上的狀態：

會觸發 render 的響應式屬性（Reactive Properties）

@property({ type: Number })
count = 0

它的作用只有一個：

當值變化 → 觸發更新流程 → 重新 render

3.1 Lit 不區分 state / props

在 Lit 中：

@property()
value = ''

既可以是：

• 外部傳入（props）
• 內部維護（state）

Lit 不關心來源，只關心變化。

四、為什麼 Lit 沒有“狀態管理方案”？

因為 Lit 的作者認為：

“狀態管理”是應用層問題，不是組件層問題

所以 Lit：

• 不提供 store
• 不提供 context API
• 不強推數據流方向

五、那複雜狀態放哪？（Important）

Lit 官方推薦的方式是：

外部狀態容器（Plain JS）

export const appState = {
  user: null,
  theme: 'light'
}

組件只是：

@customElement('user-info')
class UserInfo extends LitElement {
  @property() user

  render() {
    return html`${this.user?.name}`
  }
}

事件驅動（Event-first）

this.dispatchEvent(
  new CustomEvent('login', {
    detail: user,
    bubbles: true,
    composed: true
  })
)

由外部系統負責：

• 接收事件
• 更新狀態
• 再把新狀態傳回組件

與任意狀態庫集成

Lit 不關心你用什麼：

• Redux
• Zustand
• MobX
• RxJS
• XState

只要：

store.subscribe(() => {
  element.value = store.state.value
})

六、Lit 的“反 Hook”哲學

在 React 中：

const [count, setCount] = useState(0)

在 Lit 中：

count = 0

然後：

this.count++

Lit 的觀點是：

組件實例本身就是狀態容器

不需要再套一層抽象。

七、一個非常容易誤用的點（IImportant）

不推薦在 Lit 組件裏做：

• 複雜業務狀態流轉
• 多來源數據合併
• 大量副作用管理

推薦：

• 把 Lit 組件當成 “可複用 UI 函數”
• 把業務邏輯上移到應用層

八、Context / Provide / Inject 怎麼辦？

如果你確實需要跨層級共享數據：

8.1 官方方案：@lit/context

const themeContext = createContext('theme')

@provide({ context: themeContext })
theme = 'dark'

但注意：

這是可選工具，而不是核心能力

Lit 並不鼓勵大量使用 Context。

九、為什麼 Lit 更適合 Design System？

因為 Design System 的本質是：

• 低狀態
• 高複用
• 穩定 API
• 長生命週期

而 Lit 的組件：

天生符合這些特徵

十、與 Vue / React 狀態模型的本質差異

十一、一個非常重要的工程經驗

當你覺得 Lit “不好管理狀態”時，
往往是你在用 Lit 做“不該由組件完成的事”。

這是一個架構信號。

十二、總結一句話

Lit 的狀態管理哲學不是“怎麼管理”，
而是“不要在這裏管理”。