Lit 如何在非 Chromium 浏览器中使用 @lit-labs/router（URLPattern 依赖与 polyfill 方案）-平芜编程栈

Lit 如何在非 Chromium 浏览器中使用 @lit-labs/router（URLPattern 依赖与 polyfill 方案）

【免费下载链接】litLit is a simple library for building fast, lightweight web components.项目地址: https://gitcode.com/GitHub_Trending/li/lit

如果你的 Lit 项目使用了@lit-labs/router，并且需要在非 Chromium 浏览器中正常运行，核心问题是这个包依赖URLPatternAPI：原生URLPattern目前只在 Chrome、Edge 和其他 Chromium 内核浏览器中实现（这一点在 packages/labs/router/README.md 的 Status 一节中明确说明）。没有原生实现的浏览器中，路由匹配会直接不可用。解决方案同样是文档给出的：安装 URLPattern polyfill（仓库指定的是urlpattern-polyfill），并在路由代码执行前把它挂到window.URLPattern上。本文按“确认依赖 → 安装 → 注入 polyfill → 验证路由渲染”的顺序，走通这条路径。

为什么非 Chromium 浏览器必须处理 URLPattern

先看这个包对URLPattern的实际使用方式（来源：routes.ts）：

使用PathRouteConfig（{path: '...'}）声明路由时，内部会执行new URLPattern({pathname: route.path})，并缓存到WeakMap中；
路由匹配通过pattern.test({pathname})完成，参数提取通过pattern.exec({pathname})的pathname.groups完成；
使用URLPatternRouteConfig（{pattern: new URLPattern({...})}）时，路由匹配还会受一条限制：只检查当前 origin 下的pathname和search。

也就是说，只要路由配置存在，URLPattern构造器就一定会被调用。而Router控制器在宿主机元素连接时（hostConnected）会立即调用this.goto(window.location.pathname)（见 router.ts），首次路由匹配就发生在元素插入 DOM 的那一刻。因此 polyfill 的注入必须完成在宿主元素连接到文档之前。

准备条件与安装

@lit-labs/router的 package.json 中声明的依赖是lit: ^2.0.0 || ^3.0.0，即项目里已有 lit v2 或 v3 即可。polyfill 的包名urlpattern-polyfill出现在两处文档依据中：

README Status 一节推荐的 polyfill 名称；
package.json 的 devDependencies 中的urlpattern-polyfill: ^5.0.5（仓库自身的版本参考值）。

在你的应用中执行：

npm install @lit-labs/router urlpattern-polyfill

在页面中注入 polyfill

仓库测试页 router_test.html 给出了官方采用的注入方式，两个<script type="module">按顺序放在<head>中，polyfill 脚本在前、应用脚本在后：

<!doctype html> <html> <head> <script type="module"> import {URLPattern} from 'urlpattern-polyfill'; if (!window.URLPattern) { window.URLPattern = URLPattern; } </script> <script type="module" src="./router_test_code.js"></script> </head> </html>

这段代码的两个要点：

if (!window.URLPattern)条件判断让 Chromium 浏览器继续用原生实现，其余浏览器使用 polyfill，同一份页面代码两端都能跑；
polyfill 脚本声明在应用脚本之前，保证在应用模块（其中会创建Router/Routes实例）执行前，window.URLPattern已经就位。

把这个模式套到你自己的页面时，替换./router_test_code.js为你自己的应用入口模块即可，其余部分保持不变。

接一个最小路由，确认渲染路径

注入 polyfill 之后，按 README 的 Overview 写一个最小的顶层路由。Router是页面级单例，负责安装全局click和popstate监听（一个页面只应有一个实例），并可在构造函数中直接携带路由配置：

import {html, LitElement} from 'lit'; import {Router} from '@lit-labs/router'; class App extends LitElement { private router = new Router(this, [ {path: '/', render: () => html`<h1>Home</h1>`}, {path: '/projects', render: () => html`<h1>Projects</h1>`}, {path: '/about', render: () => html`<h1>About</h1>`}, ]); render() { return html` <main>${this.router.outlet()}</main> `; } }

元素插入 DOM 后，Router会立即对当前location.pathname执行一次goto()，outlet()渲染当前匹配路由的模板；后续的锚点点击和前进/后退导航由已安装的全局监听接管。

验证方式

仓库自己的测试（router_test.ts）展示了这套路由的验证思路，可以直接借用到非 Chromium 浏览器的手动验证上：

初始路由渲染：把页面 URL 设为/，将宿主元素追加到文档，等待updateComplete后检查元素shadowRoot的innerHTML是否包含根路由的模板。仓库测试中对应的断言示例是assert.include(el.shadowRoot!.innerHTML, '<h2>Root</h2>')（文档示例，<h2>Root</h2>是该测试元素自己的模板，替换为你自己路由的模板内容）；
点击导航：点击路由内的<a>链接，等待更新后检查 shadowRoot 中出现了目标路由的模板；
后退导航：调用history.back()并等待popstate，确认渲染回退到之前的路由。

这三步覆盖了Router安装的全局click与popstate监听以及首次goto()，全部通过即可认为 polyfill 方案在当前浏览器中生效。

已知行为差异与限制

polyfill 的参数行为差异：CHANGELOG.md 0.0.2 版本记录：传给render和enter的params可能包含undefined值，原因是urlpattern-polyfill把未匹配的可选组设为undefined而不是空字符串（对应 urlpattern-polyfill 的 issue 66）。编写 render 回调时应对参数可能为undefined保持容忍。
非 origin 内匹配不生效：URLPattern本身可以匹配协议、主机名、端口，但路由匹配只在当前 origin 内检查pathname与search（routes.ts 中URLPatternRouteConfig的注释说明）。
Labs 状态：README 顶部的 WARNING 指出该包属于 Lit Labs，为收集设计反馈而发布，可能引入破坏性变更甚至停止维护，生产使用前应先阅读 Lit Labs 文档。
版本参考：仓库中@lit-labs/router当前版本为 0.1.4，对lit的依赖范围是^2.0.0 || ^3.0.0；polyfill 版本仓库内部使用^5.0.5，作为安装时的版本参考。