LitElement 3.0 与 lit-html 2.0：早期预览版

今天我们发布了我们的旗舰库 LitElement 和 lit-html 下一个主版本的首个预览版。

这些版本包含了我们计划做的大部分破坏性变更，以及我们想从之前版本保留的大部分功能。它们目前还不完全具备完整的功能或完全稳定的 API。值得注意的是，它们目前还不支持 IE11 等旧版浏览器，或需要 Web Components polyfill 的浏览器。

我们对当前版本的库非常满意——它们快速、轻量且稳定（耶！）——在某些方面，我们并没有太多紧迫的需求来进行破坏性变更。我们不会轻易进行破坏性变更。但有一些令人信服的理由支持我们认为将改善使用 LitElement 构建的组件和应用的用户体验的变更。

1. 性能

   我们发现，我们的一些浏览器 bug 解决方案代码和自定义抽象层阻止了我们希望进行的优化。

2. 体积

   相同的代码，以及我们广泛的公共 API，增加了字节数。我们始终希望找到让库更小的方法。

3. 功能和 API 清理

   一些功能在当前架构下很难以低成本的方式添加，或者不进行破坏性变更就无法真正改进。

4. 服务端渲染

   lit-html 有一个非常灵活和可定制的 API，在某些方面更像是一个模板系统构建工具包，而不是一个单一的模板系统。但这种灵活性使 SSR 复杂化了，SSR 需要对服务端渲染的 HTML 如何映射到模板做出假设。SSR 只有在默认的、未自定义的 lit-html 中才能良好工作，因此限制自定义可以使 SSR 更可靠。反正很少有开发者使用自定义 API。

我们还希望通过限制对 DOM 的访问来使指令 API 兼容 SSR。

这些是新的主版本，因此存在一些破坏性变更，但我们希望尽可能减少对用户的干扰。我们将破坏性变更限制在不影响大多数用户的范围内，或者只需要进行机械性的更改（比如更改导入）。

请参阅 README （LitElement、 lit-html） 和 CHANGELOG （LitElement、 lit-html） 以获取最详细的变更列表。

最重要的变更：

• 不再直接支持自定义 lit-html 的语法。templateFactory 和 TemplateProcessor API 已被移除。

• 公共 API 已被最小化，以便更好地进行压缩和未来的演进。

• lit-html 指令 API 已更改为基于类的形式，并持久化指令实例。指令应该更容易编写，也更容易兼容 SSR。

• LitElement 装饰器不再从主模块导出——它们需要单独导入或从新的 lit-element/decorators.js 模块导入。这意味着不使用装饰器的用户可以获得更小的应用体积，并为当前 TC39 JavaScript 提案到来时实现新装饰器打开了大门。

• lit-html 不再使用 instanceof 或模块级别的 WeakMap 来检测特殊对象（如模板结果和指令），这应该会改善单个应用中多个 lit-html 副本的兼容性。我们仍然建议对 npm 包进行去重，但现在更多情况可以正常工作。

• Safari 12 有一个严重的模板字面量 bug，lit-html 中不再对此进行兼容处理。如果你需要支持 Safari 12，你将需要将模板字面量编译为其 ES5 等效形式。请注意，babel-preset-env 已经为存在问题的 Safari 版本做了这件事。

变更日志中还列出了更小的变更。总的来说，我们希望这些版本对大多数用户来说是直接替换的，或者只需要更新装饰器的导入。

运行：

npm i lit-element@next-major

和/或：

npm i lit-html@next-major

我们正在将 LitElement 和 lit-html 的下一个版本移入一个 monorepo。请在 当前 lit-html 仓库 中提交 issue，使用 [lit-html] 或 [lit-element] 前缀。我们预计，与任何预发布一样，会有一些常见问题需要我们修复。请先搜索你的问题。下一个主版本的 issue 将带有 lit-next 标签。

对于下一个预览版，我们将专注于浏览器和 polyfill 支持，特别是 IE11。