文档说明
这份材料是给刚开始接触Web开发的人准备的, 文章里面不会出现让人看不懂的难懂词语, 代码可以直接复制下来就使用。
你会逐步地了解Next.js这个工具主要放在什么位置, 它解决了行业里面的哪些问题, 还有它和传统的那些开发方法最大的不同在哪里, 从零开始建立项目, 弄清楚三种最主要的渲染方式是怎么回事, 做完一个全栈风格的实战任务, 任务是去调用外部的API然后对数据库进行增加、删除以及修改数据操作, 到头来就能学到企业里边最推荐的做法和适合使用的场合, 读完以后就能自己独自把完整的项目开发和上线完成。
一、现在的人可能会去弄明白, 那个叫做Next.js的具体是怎么回事。
Next.js它是由公司来开发的, 它是Meta官方所推荐的React全栈Web开发框架。
它将前端页面渲染能力、后端服务逻辑、路由系统、数据获取手段、性能优化措施以及部署上线过程, 这些全流程的能力, 全都整合进了一套代码里去。这样的做法, 就彻底打破了那个传统式的壁垒。
所谓传统式的壁垒就是大家觉得前端那边只管着做页面, 而后端那边只管着提供接口。现在呢, 通过这种方式, 让你只需要会使用React这个语法, 就可以开发出那种高性能的, 同时也是对搜索引擎友好的, 并且安全可靠的全栈Web应用程序。
从简单的那个意思去说, 就是只依靠着一套React代码, 就能同时搞定前端以及后端的这些事情, 让以前非得分开写前端项目和后端接口项目这种麻烦的情况不复存在。
二、在传统的Web开发里面, 有一个核心的痛点问题, 而这个问题正是Next.js解决之道所要对付的地方。
在Next.js这种技术被大家广泛使用并且普及开来之前呢, Web开发这个领域主要存在两种运作模式, 这两种模式都有那些根本性的问题无法回避和解决的核心痛点, 正是由于这些原因的存在, 才导致了Next.js技术的诞生。
2.关于第1点, 也就是传统开发模式里面存在的两种主要情况, 大家需要去看清楚各自的核心特点是啥, 同时也要去发现那些痛点是传统的办法怎么都没法彻底解决的。
传统的、使用服务器端来把页面渲染好的那种办法, 像什么PHP或者JSP啊还有用Java做模板的那种情况。
页面的这个HTML结构是在服务器端生成完毕之后, 再打包返回给浏览器的, 这样一来, 前面的前端代码和后面的后端代码就紧紧地绑在一起了, 耦合程度可以说是非常高。
-
前后端之间的绑定关系过于紧密, 导致前端在修改页面的过程中需要同步等待后端进行配合动作, 这使得整体的开发效率变得极其低下。
-
页面的跳转会触发全量的刷新动作, 这让人体验到的感觉很差。
-
无法使用现代React或者Vue前端生态, 因此交互能力弱。
在前面的部分和后边的部分是分开的状态, 这种分离是通过React单页面应用以及独立的后端应用程序接口来实现的。
前端这边, 程序员会专门去写一个单页面的应用程序, 然后, 这个程序会通过那个现在大家都知道的fetch或者axios这样的东西, 去调用后端提供的各种接口, 就这样子前后端就完全分开了。
-
首屏出现严重的白屏现象, 因为系统必须要先把完整的JS包下载完毕, 然后在去渲染页面, 然后再进行数据的请求操作, 这样的情况会导致在低端手机设备上或者是网络环境比较差的时候, 用户的体验感觉非常糟糕。
-
SEO存在天生的一个缺陷, 那就是页面的内容是通过JS代码动态渲染的, 这就导致搜索引擎的爬虫程序没有办法抓取到有效的内容。
-
开发成本的投入量是非常大的: 针对一个非常简单的用户新增功能需求来说, 前端开发人员需要去编写相应的页面内容, 与此同时后端开发人员也需要去编写相关的接口程序, 在此之后双方还必须进行联合调试工作, 并且还要处理包括跨域、错误现象在内的一些复杂问题, 总而言之就是代码的总撰写数量实现了一翻倍的增加状态。
-
安全风险这个东西, 其实是比较高的。前端这边无法直接去操作数据库。所有进行数据操作的行为都必须是依赖接口的。当接口变得多了的时候, 特别容易出现权限遗漏这样的问题, 也容易出现问题, 叫做数据越权。
-
在前端和后端分别进行部署的时候, 情况是很复杂的。前端需要使用CDN来部署, 而后端需要用到服务器来部署。在这个过程中, 还需要去设置跨域的问题以及HTTPS协议还有缓存之类的东西。等到出了什么毛病的时候, 又得从两端同时开始排查问题。
2.关于2这个Next.js的问题而言, 它到底是在一个什么样的层面之上一次性解决所有的痛点的?
针对以上这些让人头疼的问题, Next.js给出了一种一站式的解决办法, 它的核心能力主要包含下面这些内容:
用户可以根据实际项目的需求, 自由地在多种渲染模式中作出选择。具体而言, 这些模式包含了服务端渲染、静态生成、增量静态更新以及客户端渲染这几种类型, 也就是我们常说的SSR、SSG、ISR和CSR。
这样的设计带来了双重好处一方面有效解决了单页应用所存在的白屏现象以及SEO优化困难的问题另一方面, 也成功保留了现代前端框架所带来的流畅且丝滑的用户交互体验。
全栈能力方面, 开发者不需要去专门编写单独的API接口程序了。只需要直接在React组件内部来写服务端函数即可。这样就能安全地去操作数据库了, 也可以调用那些隐私级别的接口数据了。这种做法能够让人彻底告别关于接口联调时陷入的令人痛苦的混乱局面。
这个被称为文件式路由系统的东西, 它的基本逻辑是文件夹的结构等于页面的路由。你完全不需要去手动配置任何路由规则。这样就可以以零配置的方式来实现嵌套路由、动态路由以及权限路由这些功能。。
该功能内置了全自动的性能优化方案, 其中包含了图片压缩、懒加载、代码分割、路由预加载以及字体优化等模块, 即使是新手也能写出高性能页面。
服务端代码天然隔离, 这意味着服务端逻辑永远不会发送到浏览器端去运行, 所以数据库密码、API密钥等敏感信息能够百分之百得到安全保障。
采取一体化部署的方式, 也就是使用一套代码进行一键式的部署动作, 根本不需要把前后端的服务拆开来进行单独维护, 以此来彻底地解决那些关于跨域的问题以及版本不同步的麻烦。
三、接下来, 我们把Next.js这个全栈框架和传统的Web开发模式做一个核心优势的对比。我们将从对比维度这个角度展开讨论。具体来看传统的前后端分离这种方式。再看传统的PHP以及JSP服务端渲染这种技术栈。然后重点分析Next.js所体现出的优势。
首屏加载速度
速度比较慢, 白屏出现的时间非常长。
速度是比较快的, 接下来就跳到进行全量刷新那个步骤。
速度快, 因为服务端会返回完整的网页代码, 所以页面不需要刷新就能直接跳转过去。
SEO友好度
整体质量不行, 还需要额外去做预渲染的改造工作。
情况是很好的这个, 内容直接返回。
表现非常不错, 它能够在没有任何额外配置的情况下, 让所有的搜索引擎直接进行信息抓取。
开发效率
程度比较低, 需要进行接口编写, 进行联合调试, 还要处理跨域的问题。
低，前后端耦合，改造成本高
极高，一套代码搞定前后端，零接口联调
数据安全性
依赖接口权限校验，易出现漏洞
这个情况算是比较好的, 逻辑主要是在服务端进行处理。
做得非常出色, 服务端代码实现物理隔离, 而且内部还集成了防盗用访问令牌的防护能力。
交互体验
表现得非常优秀, 实现了页面的无刷新跳转。
表现不好, 页面发生了全面的重绘。
非常优秀, 而且它还内置了路由预加载的功能, 给用户带来了属于原生的那种级别的交互体验。
性能优化门槛
高，需手动配置代码分割、图片优化等
情况比较低劣, 改进能力存在局限。
极低, 框架内置了全自动优化功能, 大家可以直接拿来使用。
部署运维成本
这个做法是高高的, 把前端和后端分开去部署, 然后分别去做配置。
在过程中, 需要去把这个服务端的运行环境给准备齐全。
极低，一键部署，一体化运维
无JS兼容性
情况是完全不能用了, 那个页面显示出来的是白屏。
可以使用, 不过其交互表现存在不足。
这个是可以使用的, 内容也能够正常地进行展示, 同时表单也是可以进行正常提交的。
四、这是一个快速入门指南, 大家可以在5分钟之内, 从零开始, 搭建出自己的第一个Next.js项目, 现在我们要进行到4.1阶段, 也就是环境准备这一部分。
只需要安装 Node.js 18.17及更高版本的软件, 你前往其官方网站, 去下载最新的长期支持版本, 然后按照默认设置一路点下去完成安装过程就可以了, 当你成功安装了那个软件之后就去打开终端这个工具, 然后在里面执行下面列出的那些命令, 要是最终屏幕上能够显示出当前所使用的版本号的话就说明这项任务已经顺利完成了。
node -v4.现在大家要做的事情呢, 就是去创建一个项目。
打开那个终端程序, 然后去到你想要放项目的文件夹里面去, 接着执行下面写的这个用来创建的东西的那个命令:
npx create-next-app@latest my-first-next-app在执行命令之后, 屏幕上会展现出可供选择的配置项目, 对于刚刚接触的新手用户来说, 只需要持续点击回车按键来选择预设的选项就可以了, 这些预置的配置方案里面涵盖了CSS以及App这两个部分, 其中的App指的是当前最新版本的路由系统。
4.第三步, 我们要开始启动这个项目。
在创建完毕之后, 请按照顺序依次执行以下的这些命令, 从而进入对应的项目文件夹并且启动开发服务器。
在确认已经成功完成启动操作之后, 打开你电脑里面使用的浏览器, 然后去访问那个位于端口号是3000的地址, 当你看见屏幕上出现的是Next.js这个框架提供的欢迎页面显示出来, 这说明你的项目搭建工作已经顺利完成了。
4.对于那些刚入行的新手来说, 必须要把那些最核心的, 也就是项目结构的方方面面都搞懂。
在app这个文件夹的下面, 每一个page.tsx这样的文件, 都会自己去生成一个和它对应的页面路由, 这一点是自动完成的, 完全不需要人工去配置那些乱七八糟的事情, 而这个路根据分类的话, 一共可以分成三种不同的类型, 具体如下。
基础规则是, app文件夹内部的层级结构的构成方式等于网址URL的格式, 只有当大家在这个路径里面创建了page.tsx这个文件之后, 这个路径才能获得被访问的资格。
固定路由指的是, 在文件夹名字里不带等于号，也就是把网址写成死值。
app/about/page.tsx → 访问 /aboutapp/blog/page.tsx → 访问 /blog
所谓的动态路由, 其实就是指那种文件夹的名称里面带有一个等于号, 这个等于号后面跟着可变参数, 从而能够形成一个可以动态变化的网址。
app/blog/[slug]/page.tsx → 访问 /blog/1、/blog/abc、/blog/任意值关于代码的存放位置, 还有那个路由方面的对应关系。
你的项目目录 → 浏览器访问地址└── app/
├── page.tsx → localhost:3000/ (首页)
├── about/
│ └── page.tsx → localhost:3000/about (固定路由)
└── blog/
├── page.tsx → localhost:3000/blog (固定路由)
└── [id]/
└── page.tsx → localhost:3000/blog/123 (动态路由)
五、Next.js 四大核心渲染模式详解（含代码示例）
渲染方式这一件事是Next.js里头最关键的核心的那种东西, 它决定了说页面是在什么时候去生成的, 同时也决定了说数据是在什么时候去获取的, 这玩意儿会直接影响到页面的那种运行速度好不好, 还有搜索引擎优化做得怎么样, 以及服务器那边压力大不大, Next.js这个框架里的App目录那部分是原生支持四种核心渲染方式的, 分别是所谓的SSR、SSG、ISR、CSR这个四个, 根本不需要去搞那些特别复杂的配置, 也就是写那么几行代码就能够把这个模式给换过来, 而且所有给出的这些例子都是基于那个公开可用的文章API来的, 大家可以直接把这些代码复制下来然后跑起来。
5.SSG, 也就是通常所说的站点静态生成, 它的核心定义。
SSG是Next.js默认采用的渲染模式, 同时也是性能达到最优的那种。
具体是什么样子呢, 就是在项目构建的过程之中会执行, 也就是当你运行那个命令npm run build的时候, 这时候它会提前去把数据给获取到, 然后进行渲染, 最终生成完整的静态HTML文件, 那么当项目完成部署以后, 不管是谁来访问这个网站, 系统都会直接把这个预先生成的静态文件返回给对方, 这样一来就完全没必要让服务端再重复地去执行代码了, 也就不用再去查询接口或者数据库了。
特点：
适用场景
有一些属于静态内容的页面, 由于它们更新得并不频繁, 因此可以作为此类页面来看待, 比如企业官网、个人博客、帮助文档、营销落地页以及静态新闻列表。
这个部分讲的主要是核心优势, 并且还配有完整的代码示例。
需要新建一个新的文件, 这个文件的目录路径是 app, 子目录是 ssg - posts, 文件名字是 page . tsx, 然后在里面写下下面的这些代码内容:
验证方式
在执行 npm run build 这个命令来将项目打包的时候, 大家可以在打包产生的日志信息里面去寻找那个特定的页面, 当这个页面的状态位置被标记成了 () 之后, 这个情况就说明了该页面已经成功通过静态生成的方式进行了渲染, 也就是代表了 SSG 静态生成这一过程已经完成并取得了成功。
5.所谓2, 就是指SSR这个概念, 而SSR的全称是什么呢? 它是Side后面跟的那个服务端渲染的意思。
SSR这个概念指的是动态服务端渲染, 在用户每一次发起页面请求的时候, 服务端那边都会去实时执行那些数据获取的操作, 然后它会去渲染出一个完整的HTML页面, 最后再把那个页面返回给浏览器。并且, 针对每一次的网页请求行为, 它都会选择重新去执行相关的代码程序, 以及去拉取最新的必要数据信息。
特点：
适用场景
这种动态页面, 它的特点是非常强的实时性, 还有非常强的个性化。具体来说, 这包括像实时数据这样的仪表盘, 个人的中心页面, 商品详情页面这个里面的库存是实时在发生变动的, 还有那种需要执行实时权限校验操作的页面。
这个部分讲的主要是核心优势, 并且还配有完整的代码示例。
需要在app目录下面新建一个叫做ssr-posts的文件, 并且在这个文件里面再创建一个名字为page的tsx类型的文件, 然后在创建好的这个文件内部把下面列出来的代码内容填写进去。
验证方式
执行npm run build 将项目完成打包, 在输出的那个打包日志里面, 这个页面会被标注成 λ () , 这个标记的意义在于说明该页面采用的是SSR动态渲染的方式来进行处理的。
启动生产服务 npm run start, 访问页面后多次刷新, 可看到页面上的请求时间每次都会更新, 验证每次请求都重新渲染。
5.ISR, 它的全称叫做增量静态再生成, 这个概念所表达的核心定义就是。
ISR是Next.js的一个功能很厉害的东西, 它把SSG那种特别快的性能优势还有SSR那种能实时出结果的优势给结合到一块儿去了。
这个东西在做项目构建的时候, 会先把那些静态页面给生成好, 部署上线之后, 会根据你设置好的那个时间间隔, 在后台默默地自动去拉取新的数据, 然后把更新的静态页面也给渲染出来。整个过程, 不需要你去重新构建项目, 也不需要重新部署项目。
静态页面的那种访问速度, 这个是能够被支持到的, 而且数据还能做到自动地、定期地进行更新操作。
特点：
适用场景
对于那些访问量比较高但是更新频率并不太高的内容来说, 是有一种需求存在的, 这种需求就是要对它们进行定期的重新处理。
具体的包括新闻类的资讯列表情况, 电商领域里面的商品列表展示情况, 还有博客文章的相关情况, 以及论坛帖子列表的具体状况等, 这些在操作的时候是完全不需要做到实时更新的这一步的, 仅仅按照一定的时间节律去更新就完全够了。
这个部分讲的主要是核心优势, 并且还配有完整的代码示例。
在当前的项目目录下, 去创建一个新文件, 并且把这个新文件的名字定为`app/isr-posts/page.tsx`, 然后在这个文件里面, 把下面提供的这一堆代码给写进去。
// app/isr-posts/page.tsx 对应访问路径 /isr-posts// 增量静态再生成，设置60秒重新验证更新一次数据
interface Post {
userId: number;
id: number;
title: string;
body: string;
}
// 设定页面缓存有效期，单位：秒
// 60秒内的所有访问，都返回缓存的静态页面；60秒后首次访问，后台自动更新页面
export const revalidate = 60;
// 构建时预执行，后续每60秒自动重新执行更新数据
async function getISRPosts(): Promise<Post[]> {
const res = await fetch('https://jsonplaceholder.typicode.com/posts?
_limit=10');
if (!
res.ok) throw new Error('数据获取失败');
return res.json();
}
// 页面组件
export default async function ISRPostsPage() {
const posts = await getISRPosts();
// 页面生成时间，验证缓存更新
const generateTime = new Date().toLocaleString();
return (
<div className="max-w-3xl mx-auto p-6">
<h1 className="text-3xl font-bold mb-4">ISR增量静态更新文章列表</h1>
<p className="mb-6 text-gray-500">本页面每60秒自动更新一次，当前页面生成时间：{generateTime}</p>
<div className="space-y-4">
{posts.map((post) => (
<div key={post.id} className="border rounded-lg p-4 shadow-sm">
<h2 className="text-xl font-semibold mb-2">{post.title}</h2>
<p className="text-gray-600">{post.body}</p>
</div>
))}
</div>
</div>
);
}
验证方式
执行 npm run build 打包项目以后啊, 在打包日志当中, 该页面会标记为 (ISR), 这代表的就是对增量静态更新的配置确实是成功了。
你需要启动那个生产服务, 也就是执行 npm run start 这个命令, 当你第一次去访问页面的时候, 会记录下当前生成的时间, 随后如果在六十秒之内进行刷新操作的话, 所看到的时间内容是不会发生变化的, 因为这个系统返回的是被缓存起来的静态页面内容；而当六十字以外的时间段你再次刷新页面的时候, 页面上的显示信息就会被更新为最新的一次生成时间, 这样就可以确认后台那种自动更新的机制确实起作用了。
5.4. CSR指的是Side这一部分, 其中文意思是客户端渲染, 这里是关于它的核心定义。
CSR这个缩写, 指的就是客户端渲染这一回事, 这是传统的基于React的单页面应用也就是SPA里面的那种核心的进行渲染的模式。在这样的模式里, 服务器端这边, 仅仅是会返回一个空的HTML模板过来, 而这个模板里面是包含了对于JS文件的引用内容的。
至于说页面的这个渲染过程, 还有数据的获取等等逻辑, 全部都是要在那个浏览器端, 也就是说客户端这里去执行的。这个过程是通过使用JS代码来动态地生成页面的具体内容, 然后把这些内容插入到之前提到的HTML结构中去, 以此来完成整个页面的展示效果的。
简单地说, 服务端只交付一个空壳, 浏览器需要自行加载JS文件、获取数据以及渲染页面, 这种模式在Next.js中也属于需要手动开启的渲染类型, 其对应的代码标记是'use'。
特点：
适用场景
这些页面具有强交互的特点, 并且不需要进行SEO优化, 同时数据会频繁变动, 比如后台管理系统、用户个人中心也就是非公开内容部分、在线编辑器、社交应用中的动态feed以及游戏类的Web应用。
这个部分讲的主要是核心优势, 并且还配有完整的代码示例。
新建名称为 app/csr-posts/page 的 txt 文件, 把下面的代码写进去, 这里面明确标记出来了客户端渲染的情况, 用来适配那种复杂的需要交互的操作场景。
验证方式
你需要执行名为npm run dev的命令, 以此来启动开发服务的运行, 接着你要去访问位于端口号为3000的路径之下名为csr-posts的网页地址, 在这之后你将看到所打开的页面首先会显示出由加载中所组成的字样, 随后该页面会将具体的内容予以渲染出来, 这一操作步骤的目的主要是为了对客户端渲染流程进行验证。
启动浏览器, 找到其中的开发者工具这一个选项并打开它, 接着切换到特定的那个面板位置, 之后对页面执行刷新操作, 在这个时间点能够观察到服务端仅仅只返回了名为csr-posts相关的HTML文件以及JS文件, 而数据请求这个行为具体是使用fetch技术完成的, 并且这一步操作其实是在客户端这个地方发起的。
用户需要在搜索框内输入关键词, 比如说是"test"这样的内容, 这时候页面的数据会根据情况实时地发起重新请求的动作同时进行更新, 这种操作是完全不需要去刷新整个页面的方式的, 通过这一过程就能够对客户端的交互表现以及动态渲染的这些能力进行验证检查。
六、核心实战: 有两个必学示例, 分别是调用第三方API以及进行数据库增删改查。
以下的示例代码, 你可以直接复制, 然后去运行, 全程都是基于最新的Next.js的App路由模式来做的, 同时, 它也严格地符合了, 企业级的开发规范。
调用第三方应用程序接口的时候, 这里边有两种特别常用的方法, 对于这些刚刚入门的人来说, 必须要搞清楚是怎么一回事。
我们以公开的「文章数据API」为例, 其地址是位于这个地方的那个地方, 不需要去申请密钥, 就可以直接进行调用。
在Next.js里面进行API调用的时候, 它被分成了服务端调用和客户端调用这两种情况。一般来说, 我们优先推荐大家使用服务端调用的方式这样做, 性能会更好一些同时对SEO也更友好并且完全没有跨域方面的问题存在。
推荐采用的是方式1, 这种情况指的是服务端组件调用, 它在大多数场景下都是首选方案, 覆盖了百分之90的情况。
在Next.js这个开发框架里头, 如果一个组件是没有加上 'use ' 这个标记的话, 那么它默认的情况下就是一个服务端组件, 它的代码只会只在服务的这一端去运行, 并且开发者是可以直接地去运用 async 和 await 这两个关键字来调用那些应用程序接口的, 完全就不需要你去担心和处理什么状态管理的那些事情。
创建一个新的文件, 路径是 app/posts/page.tsx, 并且把下面的这些代码写进去。
// app/posts/page.tsx 对应访问路径 /posts// 无'use client'，默认是服务端组件，代码只在服务端运行
// 定义接口返回数据类型
interface Post {
id: number;
title: string;
body: string;
}
// 服务端调用第三方API
async function getPosts(): Promise<Post[]> {
// 调用第三方API，Next.js默认会缓存结果，避免重复请求
const res = await fetch('https://jsonplaceholder.typicode.com/posts?
_limit=10');
if (!
res.ok) throw new Error('接口请求失败');
return res.json();
}
// 页面组件，直接async/await获取数据
export default async function PostsPage() {
// 直接在组件中获取数据，服务端执行，前端看不到接口调用逻辑
const posts = await getPosts();
return (
<div className="max-w-3xl mx-auto p-6">
<h1 className="text-3xl font-bold mb-8">第三方API文章列表</h1>
<div className="space-y-4">
{posts.map((post) => (
<div key={post.id} className="border rounded-lg p-4 shadow-sm">
<h2 className="text-xl font-semibold mb-2">{post.title}</h2>
<p className="text-gray-600">{post.body}</p>
</div>
))}
</div>
</div>
);
}
保存后，访问 :3000/posts，即可看到渲染好的文章列表。
核心优势：
方式2是由客户端的这个组件来进行调用, 这种方式是专门给那些需要做到实时去进行交互的场景来使用的。
要是你的页面里头需要那种让用户去点按钮, 再或者是进行实时的这种输入操作, 那这样的用户交互场景下, 就必须得去使用客户端组件了, 同时呢还要加上那个 'use ' 的这个标记, 它的这个实际使用的这个方法和传统的那个 React 的方法其实是一样的。
新建一个路径为 app/-posts/page.tsx 的文件, 然后把下面的这些代码给写进去。
连接数据库, 实现完整的增加、删除、修改以及查询等操作。
我们使用作为数据库, 这一点是明确的, 大家不需要去安装任何跟数据库服务有关的东西, 同时也绝对没有必要去配置什么账号和密码, 这样的设计就是为了让每个人都可以开箱即用, 哪怕是新手也可以做到零门槛操作, 如果将其与 Next.js 的搭配结合在一起进行考虑的话, 那么更是需要强调的一点在于, 人们完全不需要去编写任何形式的 API 接口代码, 就能够在安全得到保障的前提之下, 顺利实现对数据库中数据的增加、删除、修改以及查询功能。
步骤1, 也就是先进行依赖的安装这个操作。
在项目终端的位置上执行以下的命令这个动作, 来安装数据库这个领域里面所需要的依赖内容。
npm install better-sqlite3# 类型声明，TypeScript项目需要
npm install -D @types/better-sqlite3
这一步要做的事情是, 创建一个专门用来处理数据库连接的工具类。
创建新文件, 路径是 lib/db.ts, 把下面的那些代码内容写进去, 这样做的目的就是为了去实现与数据库的连接操作, 以及完成对数据表的初始化工作。
按照步骤三的内容, 进行创建操作, 以便实现增删改查这样的逻辑。
先新建出一个叫做 app 目录下的 users 点 ts 后缀的那个文件, 往里面写入下面这些代码, 让那些所有的函数都被打上服务端的操作这样的标记, 使得这段代码只会能够在服务端运行, 而绝对不会暴露给前端来看。
步骤4: 创建页面, 实现完整的用户管理功能。
你需要新建一个名为 app/users/page.tsx 的文件, 在这个文件中写入以下的代码, 这样就可以实现表单提交, 并且能够展示用户的列表, 同时还支持对用户的修改和删除这一系列功能的操作:
步骤是第五个, 也就是运行之后的实际效果。
把全部代码都保存好, 然后去访问 :3000/users 这个链接, 这样你就能实现。
七、Next.js企业级开发的最佳实践指南, 这是新手按照这个来操作就不会踩坑的内容。第七点第一阶段是选择渲染模式的最好的做法部分。第一个要点是要是能进行静态处理那就尽量采用静态的方式。
对于那些像是企业官方网站、个人博客文章或者产品文档这样不怎么经常需要去更新变化的页面内容, 应当优先考虑去使用SSG也就是静态站点生成技术来进行处理, 这种做法能够使得服务器承担的压力达到零, 而且访问这些页面的速度会是最快的。
对于那些具有动态性并且需要定期更新内容的页面，例如商品展示列表或者新闻资讯列表这样的, 可以采用ISR技术即增量静态重新生成的方式, 并且给其设置一个等于六十秒的过期时间，也就是让缓存保留六十秒, 这样做既能够保证数据的比较新鲜程度, 同时又避免了因为过于频繁地去查询数据库而出现性能问题。
只有在那些真的只有实时数据才需要使用纯SSR也就是服务端渲染技术的场景之下, 比如后台系统中的实时数据显示或者用户个人中心这些具有强烈个性化需求以及强实时性的页面里面, 才应该去使用cache选项值为no-store的这种方式来强制不加载任何缓存内容, 以此避免由于过度滥用这种技术方案而导致服务器负载压力变得过大。
关于客户端组件的使用要遵循最小化原则。
只有在那些确实需要进行用户交互操作的成分的时候, 譬如按钮点击事件处理、输入框的数据录入或者是状态的管理功能等情况下, 才会加上'use '这样一个标记指令, 而对于除此以外的所有其他部分, 全部都应当使用服务器端组件来处理, 以此来确保整个系统的运行性能更加优异以及安全性得到保障。
7.第二条是安全开发的最佳实践, 内容非常明确。第一点要求永远不要将数据库连接、密钥这些敏感信息写到客户端组件里面去。因为所有的敏感操作都应该放在服务端组件之中, 这样才能确保安全。第二点关于环境变量规范有一个清晰的界限。只有那些确实需要暴露给前端使用的变量, 才可以加上相关的前缀来进行标识。
但是像数据库密码或者是API密钥这种高度敏感的变量, 是绝对不能加此前缀的, 必须严格保护。第三点强调必须执行参数校验这一重要步骤。对于所有由用户提交的数据来说, 必须去做格式上的校验以及权限上的校验, 千万不要直接把这些数据写入到数据库里面去, 要杜绝安全隐患。第四点是关于代码管理的安全问题。
严禁在客户端组件中使用内联的方式处理关键脚本, 相反应当导入位于单独文件中的脚本。这样做可以避免因代码泄露而引发的问题, 确保资产安全。
7.第三部分是性能方面的优化最佳实践, 首先一点是要去使用那个内置的 Image 组件, 也就是所有的图片资源都必须是用 next/image 来处理的, 这样的话系统就能够自动地去实现压缩、懒加载还有自适应这些功能了, 从而能够有效地避免因为图片的存在而产生各种各样影响性能的问题；其次是关于内置的 Font 组件的使用, 这里建议采用 next/font 这个方式来加载字体文件, 这样做的主要目的就是为了避免出现字体闪烁以及加载速度过慢这类让人头疼的问题；再者就是路由预加载机制的应用, 开发者在用 next/link 来做页面之间的跳转操作时, Next.js 这个框架本身是会自动地对目标页面进行预加载处理的, 这种处理方式最终能够实现那种秒秒钟就能打开页面的快速跳转体验；最后还有一点非常关键的, 就是要尽可能地去避免在客户端中使用那些体积特别大的组件, 对于那些需要复杂交互效果的大尺寸组件来说, 应该使用动态导入的方式来进行处理, 具体做法是写成 (() => ('./xxx')) 这样的形式, 通过这种方式就能够在实际需要的时刻再去加载它们, 从而实现一种按需加载的效果, 这样一来就能大幅度地减少掉首屏阶段所需要加载的 代码的整体体积了。
7.这里是关于部署最佳实践的说明。优先建议选择由Next.js官方出品的部署方案, 该方案具备一键部署的功能, 无需进行额外配置, 并且能够自动扩容使用方式。其免费提供的额度已经足够支持个人项目使用, 也适合小型企业项目使用。
也可以选择使用自有服务器进行部署, 在这种情况下可以使用打包部署的方式来进行操作, 或者先执行npm run build这个命令来完成打包工作之后再用npm run start这个命令来启动生产环境下的服务。
需要特别注意的是, 在生产环境中必须关闭开发模式, 这样做可以有效避免源代码泄露的问题同时还能解决性能方面的问题。八、Next.js的适用场景以及不适合使用的场景, 我们要先关注8.1这部分内容, 也就是那些被强烈推荐去使用的场景。
首先就是企业官网, 还有品牌官网, 以及营销落地页这些类型, 它们对搜索引擎优化很友好, 首屏打开的速度也非常快, 部署起来也比较简单, 所以特别匹配这样的需求；然后是博客、文档站、内容门户或者是新闻站点这类地方, 它们可以采用静态生成加上增量静态再生的组合方式, 这样的话既能够保证访问的时候速度够快, 又能够让内容的更新变得轻松容易；再次是电子商务平台和商城站点的建设方面, 这时候可以利用服务端渲染结合增量静态再生的技术, 这样既能照顾到搜索引擎优化的问题, 又能实现价格和库存等实时信息的更新操作, 而且还能够安全地处理好订单逻辑相关的事务；接着是在SaaS应用、后台管理系统以及仪表盘的开发工作中, 因为可以进行全栈一体化的开发模式, 用一套代码就能把页面效果和后端逻辑一并解决妥当, 从而使得开发的效率成倍提高；再来看看AI应用、工具类网站这方面的情况, 可以在服务端进行安全的接口调用动作, 这样就避免了密钥信息泄露的风险现象存在, 同时还能确保前端在交互方面的良好体验获得保障；最后是移动端优先的Web应用或者PWA项目里, 因为它内置了一些性能优化的措施, 所以在网络较差的环境下使用的时候, 给人的体验效果远远超过传统的单页面应用。
8.在2这个部分里, 提到了不推荐使用的场景, 第一种情况是纯静态的、没有动态内容的单页网站, 像这种只有1到2个页面的纯静态介绍页的话, 大家可以选用更轻量级的Astro框架；第二种情况是那些已经有了成熟的、超大型微服务后端体系的项目, 这种情况下不建议用Next.js去替代现有的后端, Next.js只是作为前端渲染层存在, 用来调用那些已经存在的微服务接口比较好；第三种情况是非React技术栈的项目, 因为Next.js是基于React的, 如果项目用的是Vue或者其他的类似技术栈, 那就建议选择自己对应的框架, 比如Nuxt之类的。
九、对以上内容进行总结, 并且给出一个最核心的总结。
Next.js这个工具, 它把一个现代Web开发的流程, 给完全彻底地重新做了一遍, 所以说, 它并不是一个很简单的React框架, 相反地, 它是一套完整的、包括了前后两个部分的, 开发解决方案。