Elm-Pages 2.0

此版本代表了 elm-pages 在功能、开发人员体验和性能方面的巨大改进。它引入了一个完全自定义的开发服务器，绝对没有 webpack，当您更改 Elm 代码和数据（如降价文件）时，它可以为您提供热模块替换！它还用更灵活和通用的构建块代替了一些特定的功能，开辟了许多新的用例，并使用更少的核心概念来实现更多的可能性。所有这一切都伴随着我们在 Elm 生态系统中所期望的类型安全性和强大的反馈。在此版本之前，StaticHttp API 允许您提取数据并在预渲染页面及其 SEO 标签中使用它。也就是说，您可以呈现在构建时验证的数据，而无需加载微调器或错误状态。如果出现问题，您会收到构建错误，并且可以在用户看到之前修复它。在 v2 中，此 API 已重命名为 DataSource 以反映更广泛的用途。您不仅可以从 API 请求之外的更多地方提取数据，而且还可以在更多地方使用这些数据。如果这个概念在 v2 之前是一个重要的特性，那么在 v2 发布之后你可以认为它是整个 elm-pages 平台的基本构建块。 v2 之前缺少的最大功能之一是能够使用外部数据来确定预渲染页面。在 v1 中，将新文件添加到 content/ 文件夹（通常是 markdown 文件）是创建新页面的唯一方法。例如，此限制意味着您不能使用 CMS（内容管理系统）在外部系统中托管您的博客文章或其他页面，然后使用该外部数据为每个条目创建一个页面。使用 elm-pages v2，您可以使用任何数据源来确定路由的预渲染页面。例如，让我们看看这里的这篇博文是如何呈现的。要创建博客文章，我们可以运行 elm-pages add Blog.Slug_。页面模块名称的每一部分代表 URL 的一部分。尾随 _ 表示 slug 是动态的。您可能已经看到这样标记的路由：/blog/:slug。因此，运行此命令会构建一个模块，elm-pages v2 的基于文件的路由将使用该模块来呈现 /blog/introducing-v2 等页面。因为这些博客文章只是本博客中的本地文件，我们可以使用 DataSource.Glob 枚举我们想要的 /blog/:slug 路由的所有页面。

elm-pages 并不关心预渲染路由的数据源是什么——它只关心你有一个数据源（列出 RouteParams）。如果我们想将我们的博客文章迁移到外部 CMS 并使用 HTTP 获取博客文章，那么我们只需将该 DataSource 替换为不同的：或者上述任意组合，使用 DataSource.map2、DataSource.andThen 或来自该模块的其他组合/继续助手 如果这还不足以为您提供需要拉入站点的数据，那么还有一个额外的模块可以让您构建自己的自定义数据源。 DataSource.Port 允许您解码从自定义 NodeJS 函数调用的 JSON 数据。与任何 DataSource 一样，您在构建步骤中获取这些数据，然后将其内置到您的站点中，因此当用户在您的实时站点中打开一个页面时，这些 NodeJS 函数、HTTP 请求、文件读取等不会发生您使用 elm-pages 构建。它为您提供了添加所需的任何数据源的构建块，例如调用 shell 脚本

您可以在 NPM 生态系统中利用庞大的工具生态系统，包括具有本机依赖项的工具 - 例如，您可以使用 Sharp 从您的文件系统中获取图像的宽度/高度您可以从最终站点中删除计算和数据，以便用户获得更快速的体验 - JAMstack 的核心原则之一。例如，我喜欢在构建时使用 shiki 从 VS Code 中提取所有语法突出显示的语法，并将其提取为浏览器加载时已经解析的标记化输出（提取每个 VS Code 语言语法到您的捆绑包将不可行！）现在一个页面就像您需要的那样简单。 v1 中元数据的概念经常导致这样的降价文件：只是一个带有一些前端的空降价文件，因此页面可以被解码为元数据。然后使用 case 表达式，如果它是 blog-index-page，您可以在主 Elm 视图中呈现您的博客视图。 elm-pages 2.0 使用基于拉取的方法。你可以定义一个页面模块，然后用它来呈现一个 Elm 视图（或一个带有自己的消息和更新的迷你 Elm 应用程序）。或者，如果您需要，您可以从所有博客文章中提取元数据。由你决定。核心构建块可让您提取数据，您可以定义从何处获取数据以及如何处理数据。 elm-pages v1 建立在 Webpack 之上。它使用 Webpack 插件来运行 Puppeteer 并预渲染所有页面。这是脆弱的，是性能的主要瓶颈。 v2 删除了 Webpack 以及许多其他 NPM 依赖项。开发服务器是完全定制的，用于编译您的 elm-pages 应用程序，在开发服务器中为您提供 Elm 编译器错误覆盖，以及数据源错误覆盖。它甚至可以对页面所依赖的数据源进行热模块替换。例如，如果你有一个 DataSource 来列出每一篇在 frontmatter 中标记了特定标签的博客文章，如果你保存一个 Markdown 文件并添加或删除一个标签，它会在你在 dev 中查看页面时立即反映出来服务器。

作为此版本的一部分，我进行了大量性能调整，对于我升级的站点，我看到构建时间在几秒钟而不是几分钟内。如果您将您的网站从 v1 升级到 v2，我很想知道您之前/之后的表现！ v2 引擎盖下的核心变化之一是每次都构建一页。这是如何优化开发服务器性能以快速呈现和热重载页面及其数据的核心。引擎盖下的这种新架构也为一些实验性功能提供了动力，这些功能将成为下一个 elm-pages 里程碑的重点：无服务器渲染。无服务器函数让您可以通过最少的基础设施设置运行 JavaScript 代码，并响应 HTTP 请求。这本质上正是开发服务器正在做的事情，因此在请求时渲染页面而不是在构建时预渲染页面并没有太大的飞跃。在您提前拥有所需数据的情况下，预渲染页面仍然是理想的，但在某些情况下，您可能希望按需获取数据，甚至在提供页面时使用请求标头。例如，您可以使用身份验证标头来验证用户是否已登录，并根据身份验证检查进行重定向或提供用户页面。传统 Jamstack 站点的挑战之一是特定于用户的内容，而此功能可以在该领域开辟一些用例。请继续关注这方面的更多信息。现在，试试新的 v2！您可以通过运行 npx elm-pages@latest init my-app 来设置新应用。您还可以在 elm-pages 文档中阅读更多内容，并查看 elm-pages 包文档。如果您创建了一个闪亮的新 v2 站点，请将其提交到展示区，我很想看看您构建的内容！