PRNext 0.1.19:首次使用时编译,保留状态
在一个页面上使用的编辑器不应该将其编译工作添加到每次启动中。正在进行的表单不应该消失,因为代码编辑是在提交时到达的。 PRNext 0.1.19-alpha 通过延迟客户端编译、更有针对性的开发更新以及服务器操作和快速刷新之间更好的协调来解决这些情况。
此版本还为您提供了迁移前的更多背景信息以及使用帐户、数据库和身份验证来练习应用程序的完整示例。以下是您的项目中发生的变化、如何启用有用的选项以及它们的限制。
通过代码编辑保持工作进展
考虑一个仪表板,其布局中有一个过滤器以及一个调用服务器操作的表单。您可以在表单响应到达时保存组件。 PRNext 协调这些操作以在更新兼容时保留已安装的布局,而不是将刷新的操作引用视为再次启动页面的原因。
源未更改的操作在开发会话中保留其身份,包括缓存组件。更改的操作会获得新的身份。生产版本保留独立的身份。旧的 Flight 响应无法覆盖新一代的渲染,即使导航替换了其渲染,操作错误仍然可以观察到。
突变及其显示仍然是独立的操作。新的交互可以使旧的显示变得无关紧要,但 PRNext 永远不会再次提交突变。不兼容的编辑、某些配置更改和完整文档重新加载仍然可以重置内存中保存的状态。
打开就编译一个大工具
普通的动态导入会在编译期间生成一个块,即使在下载它等待交互时也是如此。在开发过程中,experimental.lazyDynamicImports 更进一步:它将符合条件的客户端目标保留在初始浏览器图表之外,并在转换和编译它们之前等待它们的首次使用。
使用本机编译器在 App Router 应用程序中启用此选项。编辑器、查看器或很少打开的面板是比较行为的有用场所。默认情况下该选项处于禁用状态。
export default {
experimental: {
lazyDynamicImports: true
}
};首次使用需要支付编译该子图的成本。文件在私人暂存中准备并完整发布。样式在导入解析之前加载。一旦激活,该模块就会参与 JavaScript 和 CSS 更新。已加载的 ESM 依赖项保留其身份和实时绑定;两个导入器也共享相同的 JSON 对象。
预期的好处是当您的工作流程不使用该工具时将工作移出启动状态。一起测量启动和首次使用延迟。该选项既不会改变生产块,也不会改变服务器渲染行为。
仅浏览器编辑器的示例
带有 ssr: false 的 next/dynamic 组件将编辑器保留在浏览器中。在此示例中,仅在面板打开后才请求该组件。启用延迟编译后,其合格的客户端代码将等待直到使用。
'use client';
import { useState } from 'react';
import dynamic from 'next/dynamic';
const Editor = dynamic(() => import('./editor'), {
ssr: false,
loading: () => <p>Loading the editor…</p>
});
export default function EditorPanel() {
const [open, setOpen] = useState(false);
return open
? <Editor />
: <button onClick={() => setOpen(true)}>Open the editor</button>;
}初始范围不包括 webpack 挂钩和自定义加载器。计算导入、导入属性和包含 ? 的文字路径或 # 保留普通编译。延迟图中由别名或依赖项引入的后缀会产生显式错误。无法保留身份的共享 CommonJS 依赖项和仅通过该图发现的新服务器操作也需要普通路径或合适的静态导入。
激活的样式仍会在开发生成时加载,包括并行路线。首选工具本地的 CSS 模块或选择器。该机制需要该代文件系统上的硬链接;当该环境无法创建它们时禁用该选项。
编辑样式表而不复制 JavaScript 版本
兼容的 CSS 编辑会重建受影响的包,并在当前 JavaScript 一代上发布一个小型样式生成。 PRNext 保留仍在使用的资源,包括图像、字体和源映射,而无需扫描或复制该更新的每个 JavaScript 文件。
如果您编辑一个面板的样式,然后多次编辑另一个面板,则第一个面板的修改资源在有界样式目录中仍然可用。未更改的资源在基础一代中仍可访问。出处不完整、目录过大或不兼容的更改会回退到完整版本。
增量图还将其预算划分为主要编译和样式。当项目有许多 CSS 范围时,样式可以借用未使用的容量,而无需不断驱逐主图。限制仍然是全局性的,并且当会话结束时工作将被处理。
在 macOS 上,目录通知可以组合多个更改。 PRNext 检查该源子树中的文件以检测深度编辑,无论是在开发中还是在构建--watch 中。如果验证仍未完成,它将报告可恢复错误并保留先前的构建而不启动编译循环。
在更改运行时之前了解不兼容性
源中受支持的 next/* 导入可以隐藏使用不同私有 API 的依赖项。迁移审核遵循可到达的静态导入到已安装的包中。它考虑浏览器、节点和 React 服务器组件上下文,并报告诊断背后的文件、行和导入链。
当客户端组件通过重新导出到达使用服务器边界时,它仍然是服务器边界。通过浏览器映射和安装的实现来检查对节点 API 的浏览器依赖性,而不是仅仅因为包存在而接受。
从已安装预期 PRNext 版本的项目中,从不应用迁移的检查开始:
npx --no-install prnext migrate --dry-run
npx --no-install prnext migrate --check --json该报告将检查的行为与未知的行为区分开来。计算的导入、加载器输出或遍历限制不会成为隐式成功。审计不会执行它检查的依赖模块,但评估配置可以运行项目代码。它既不是不受信任代码的沙箱,也不是兼容性证书。真正的构建和应用程序工作流程仍然是必要的。
从演示页面转移到带有帐户的应用程序
saas-reference 示例在法语和英语应用程序中结合了 Better Auth、PostgreSQL、Drizzle 和 next-intl。每个帐户都拥有自己的笔记。仪表板会检查会话,每次更改都会再次检查用户和数据所有权。隐藏按钮或仅保护页面是不够的。
身份验证表单在昂贵的密码散列之前应用共享的原子 PostgreSQL 预算。资格认证工作流程使用受控本地提供商和检查安全 cookie 的 HTTPS 代理来执行会话撤销、CSRF 拒绝和无效 OpenID Connect 回调。
在重新定位其独立输出后,对同一个应用程序进行了测试,其中有两个工作人员并删除了原始源。这是一个可验证的起点。访问规则、帐户恢复、验证和滥用限制仍然需要与您的产品相匹配。在部署中,将后端保持在覆盖转发标头的受信任代理后面的私有状态。
通过正确的检查来采用该版本
更新后,检查实际安装的版本并对齐 React 依赖项,然后重建并重新启动应用程序。如果您从 Next.js 迁移,请保留审核报告并执行经过验证的路线、表格、样式和导航。在启用之前,先比较您自己项目中的实验选项。
PRNext 仍然是具有部分 Next.js 兼容性的 alpha。功能资格涵盖 Linux、macOS 和 Windows,以及 Chromium、Firefox 和 WebKit。这些检查并不能确定总体性能增益。由于过程观察不完整,历史活动仍然没有结论;它并不能确定此版本的性能。原子开发状态发布期间早期的 Windows EPERM 失败仍然有记录,没有证明原因或具体修复。
代表性工作流程是一个有用的起点:打开冷路由,编辑其样式,提交表单并返回到以前访问过的页面。这会检查您的应用程序的版本更改,及其依赖项、身份验证和部署约束。