使用 Puck Next.js recipe 部署上线前需要检查哪些配置【免费下载链接】puckThe visual editor for React.项目地址: https://gitcode.com/GitHub_Trending/puc/puck如果你准备把 Puck 的 Next.js recipe仓库中的recipes/next目录一个基于 Next.js App Router 的 Puck 编辑器 渲染示例应用从本地开发环境带到生产环境recipe 的 README 在 Before deploying to production 一节明确列出了 4 项必须先处理的事项编辑器和 API 默认完全公开、组件配置还是示例内容、数据存储是本地 JSON 文件、公开页面默认静态渲染。这篇文章按这 4 项逐一说明在哪个文件检查、判断依据是什么、以及 README 对每项给出的要求。部署前先确认本地流程跑通上线前先确认基线流程是按你预期的方式工作的部署后的检查才有参照物。在 recipe 目录下启动开发服务器npm run dev然后访问http://localhost:3000查看首页http://localhost:3000/edit进入 Puck 编辑器编辑该页。README 描述了这套流程的实现方式核对行为时可以直接对照代码proxy.ts对 GET 请求把以/edit结尾的路由 rewrite 到/puck/[...puckPath]编辑器路由同时把直接访问/puck前缀的请求重定向回/。app/puck/[...puckPath]/client.tsx点击Publish时onPublish把{ data, path }POST 到/puck/api。app/puck/api/route.tsPOST 处理器把页面 JSON 写入database.json并调用revalidatePath(payload.path)清除对应页面的 Next.js 缓存成功后返回{ status: ok }。app/[...puckPath]/page.tsxcatch-all 路由读取同一份数据用Render渲染已发布的页面。验证方式在编辑器中发布后/puck/api返回{ status: ok }随后访问对应的/your/path应能直接渲染发布后的页面。README 也说明可以访问任意/your/path/edit创建并发布新路径的页面发布后/your/path即渲染该页。检查一保护 /edit 路由和 /puck/api 端点README 的第一条要求Protect the editor and API。/edit路由和/puck/api端点默认是公开的public by default需要你自己加上认证和授权authentication and authorization确保只有可信用户可以编辑或发布页面。代码中的依据app/puck/[...puckPath]/page.tsx的文件注释明确写着 NB this route is public, and you will need to add authentication且该路由声明了export const dynamic force-dynamicapp/puck/api/route.ts的POST处理器对请求不做任何身份校验收到数据就直接写文件。recipe 本身没有附带认证实现README 也只要求加上认证和授权具体方案由你按自己的部署环境实现这是上线前必须补上的一项否则任何访问者都能改写你的页面数据。检查二把示例组件替换成你自己的组件库README 的第二条要求Add your component library。当前puck.config.tsx里只有一个示例组件HeadingBlock单一title文本字段、render输出一个带 64px padding 的h1export const config: ConfigProps { components: { HeadingBlock: { fields: { title: { type: text }, }, defaultProps: { title: Heading, }, render: ({ title }) ( div style{{ padding: 64 }} h1{title}/h1 /div ), }, }, };README 要求用你的用户实际需要的组件和字段替换这个示例HeadingBlock。这份 config 会被编辑器app/puck/[...puckPath]/client.tsx中的Puck config{config}和公开页面渲染通过lib/get-page.ts加载数据后经Render使用共用替换时要保证组件、字段定义和你的渲染逻辑一致。检查三把 database.json 换成真实数据库README 的第三条要求Use a real database并给出了原因本地文件在多服务器实例或 serverless 部署下不可靠Local files are not reliable across server instances or serverless deployments。当前 recipe 有两个地方直接读写项目根目录的database.jsonlib/get-page.tsgetPage用fs.readFileSync读取database.json并按路径取页面数据文件注释就是 Replace with call to your databaseapp/puck/api/route.tsPOST处理器用fs.readFileSync/fs.writeFileSync读写同一个文件。替换时改动范围就是这两处getPage改为调用你的数据库读取逻辑API 处理器改为写入你的数据库但保留写入成功后的revalidatePath(payload.path)调用这是发布后让公开页面缓存失效、拿到新内容的机制。检查四选择公开页面的渲染策略README 的第四条要求Choose a rendering strategy。app/[...puckPath]/page.tsx末尾声明了// Force Next.js to produce static pages: https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamic // Delete this if you need dynamic rendering, such as access to headers or cookies export const dynamic force-static;文件头注释解释了它的作用所有由该路由产出的页面会按增量静态站点生成incremental static site generation方式静态渲染首次访问后缓存为静态文件发布页面时通过 API 路由清除缓存。README 的要求是如果页面需要请求时的数据如 headers、cookies、用户会话删掉force-static这一行。注意区分编辑器路由app/puck/[...puckPath]/page.tsx声明的是export const dynamic force-dynamic这是有意为之——该路由注释说明这种 magic catch-all 方式让公开页面保持静态渲染而/puck编辑器路由保持动态。这一项不需要改动只需确认你清楚它和公开页面策略的差别。构建、启动与最终验证package.json中提供了构建与启动脚本npm run build npm start对应next build和next start。next.config.js只开启了reactStrictMode: true没有需要额外修改的项。启动后按部署前的流程再走一遍即可核对上线状态访问/edit或任意/your/path/edit——确认已被你实现的认证保护未授权访问无法进入编辑器或调用/puck/api发布一个页面——API 返回{ status: ok }且数据写入的是你的数据库而不是database.json访问对应的/your/path——渲染的是最新发布内容验证缓存失效链路正常工作。README 给出的 4 项要求到这里已全部覆盖。需要明确的是认证方案和生产数据库都不在 recipe 内README 只指出必须替换/添加而没有给出实现这两项需要在你的部署环境中自行完成并通过上面的验证确认。【免费下载链接】puckThe visual editor for React.项目地址: https://gitcode.com/GitHub_Trending/puc/puck创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考