最近想攻关一个 node.js 框架。但愿找到一个可以帮咱们把大部分事情都作好的框架，能够直接上手快速开发。不像传统的 Express、Koa 须要配置大量中间件。按照这个想法，谷歌了一下就是 —— Next.js 了。最后完成了一个简易的博客系统，css
代码地址: https://github.com/Maricaya/nextjs-bloghtml
预览地址：http://121.36.50.175/前端
不得不说 SSR 真香，几乎没有白屏时间，加载很是快。node
来记录下学习（踩坑）的过程，这篇文章的代码都在https://github.com/Maricaya/nextjs-blog-1啦。react
先来看看 Next.js 是什么吧。webpack
Next.js 是一个全栈框架
Next.js 是一个轻量级的 React 服务端渲染应用框架。ios
它支持多种渲染方式：客户端渲染、静态页面生成、服务端渲染。git
使用Next.js 实现 SSR 是一件很简单的事，咱们彻底能够不用本身去写webpack等配置，Next.js 都帮咱们作好了。github
弱项
上面讨论了 Next.js 的不少优势，但每一个框架都有不完美的地方，尤为是在 Node.js 社区。web
做为一个后端框架，Next.js 彻底没有提供操做数据库的相关功能，只能自行搭配其余框架。（好比 Sequelize 或者 TypeORM）。
也没有提供测试相关功能，也须要自行搭配，能够选择 Jest 或者 Cypress。
如今咱们基本了解了 Next.js，接下来跟着官网作一个简单的项目吧。
建立项目
# nextjs-blog-1 是咱们的项目名称
npm init next-app nextjs-blog-1
选择 Default starter app。
进入 nextjs-blog-1，用命令行启动项目 yarn dev。
看到下面这个页面👇，就说明你的项目启动成功啦。
下面咱们为项目加上 TypeScript！
启动 TypeScrip！
第一步就是安装 TypeScript。
yarn global add typescript
建立 tsconfig.json
而后咱们运行 tsc \--init，获得 tsconfig.json，这是 TypeScript 的配置文件。
接下来安装类型声明文件，而后重启项目。
yarn add --dev typescript @types/react @types/node
yarn dev
而后咱们将文件名 index.js 改成 index.tsx。
建立第一篇文章
根目录下建立 posts 文件夹，咱们的文章放在这个路径下。
建立 posts/first-post.tsx 文件，写入代码：
// 第一篇文章
import React from "react"
import {NextPage} from 'next';
const FirstPost: NextPage = () => {
return (
<div>First Post</div>
)
}
export default FirstPost;
这个时候访问 http://localhost:3000/hosts/first-post 就能看见页面了。
Link 快速导航
官网中介绍了 Link 快速导航。
稍微了解前端同窗们可能会有这样的问题，不是有 a 标签能够导航吗，Next.js 为何要画蛇添足。
据官网介绍，Link 能够实现快速导航。咱们来作个实验，看看它和 a 标签有什么不一样。
先在项目分别中使用 a 标签、Link 标签导航，实现首页和第一篇文章互相跳转。
index.tsx
<h1 className="title">
第一篇文章
<a href="/posts/first-post">a 点击这里</a>
<Link href="/posts/first-post"><a >link 点击这里</a></Link>
</h1>
/posts/first-post.tsx
// 回到首页
<hr/>
<a href="/">a 点击这里</a>
<Link><a href="/">link 点击这里</a></Link>
点击 a 标签，每次进入 first-post、index 页面，浏览器都会从新请求全部的 html、css、js。
接下来使用 Link 标签导航，神奇的事情发生了，浏览器只发送了 2 个请求。
第二个请求是 webpack，因此真实的请求只有 1 个，就是 first-post.js。
反复在两个页面中跳转，除了 webpack，浏览器没有发出任何请求。
Next.js 到底作了什么？快速导航和传统导航有什么区别？
传统导航
咱们先来看看从 page1 到 page2，传统导航是怎么实现的👇
访问第一个页面 page1 时，浏览器请求 html，而后依次加载 css、js。
当用户点击 a 标签，就重定向到 page2，浏览器请求 html，而后再次加载 css、js。
Link 快速导航
再看相同的过程，Next.js 中的快速导航是怎么实现的。
首先访问 page1，浏览器下载 html，而后依次加载 css、js。这些和传统导航同样。
可是当用户点击 Link 标签时， page1 会执行一个 js，这个js 会对 Link 标签进行解析，点击 Link 以后请求 page2 的 page2.js，这个 page2.js 就是 page2 的 html+css+js。
请求完 page2.js 以后，会回到 page1 的页面，把 page2 的 html、css、js 更新到 page1 上。也就是把 page1 更新为 page2。
因此，浏览器没有亲自访问过 page2，而是 page1 经过 ajax 来获取 page2 的内容。
优势
因此，Link 快速导航（客户端导航）有这么多优势：
-
页面不会刷新，用 AJAX 请求新页面内容。 -
不会请求重复的 HTML、CSS、JS。 -
自动在页面插入新内容，删除旧内容。 -
由于省了一些请求和解析过程，因此速度极快。
同构代码
什么是同构？
同构是指同开发一个能够跑在不一样的平台上的程序， 这里指 js 代码能够同时运行在 node.js 的 web server 和浏览器中。
也就是代码运行在两端。
作个试验，咱们在组件里写一句 console.log('aaa')。
结果 Node 控制台、Chrome 控制台都会打印出 aaa。
注意差别
但并非全部的代码都会运行在两端。
好比须要用户触发的代码，只会运行在浏览器端。
咱们的代码也不能随意编写，必须保证在两端都能运行。好比 window，在 Node.js 中没有这个对象，就会报错。
优势
减小代码开发量, 提升代码复用量。
-
一份代码能同时跑在浏览器和服务器，所以代码量减小了。 -
业务逻辑也不须要在浏览器和服务端同时维护，减少了程序出错的可能。
全局配置 Head, Metadata, CSS
Head
title
咱们想让页面的 title 不一样，应该怎么配置？
在 Head 中配置 title，Head 会帮咱们写入 title。
<Head>
<title>个人博客</title>
</Head>
Metadata
meta 也是同样
<Head>
<meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,viewport-fit=cover"/>
</Head>
可是目前 index.tsx 和 first-post.tsx 是两个文件，难道要写入两遍吗？有没有统一写入的方法？
全局配置
建立 pages/_app.js，从官网上抄下代码，写入咱们的 tie而后重启 yarn dev。
export default function App({ Component, pageProps }) {
// Component
return <div>
<Component {...pageProps} />
</div>
}
其中 Component 就是咱们定义的 index 和 first-post；pageProps 是页面的选项，目前是空对象。
export default function App 是每一个页面的根组件。页面切换时 App 不会销毁，App 里面的组件会销毁。咱们能够用 App 保存全局状态。
CSS
也是同样，全局的 CSS 放在 _app.js 中。由于切页面的时候 App 不会被销毁，其余地方只能写局部 CSS。
imprort '../styles/global.css'。
绝对引用
写相对路径有点麻烦，能不能指定根目录写绝对路径呢？翻了翻官网，发现 Next.js 提供了相似的功能。
配置 tsconfig.json，定义根目录。
{
"compilerOptions": {
"baseUrl": "."
}
}
重启项目，就能够绝对引入 css 啦：
imprort 'styles/global.css'
静态资源
next 推荐放在 public/ 里，可是我并不推荐这种作法，由于不支持改文件名。
有前端基础的同窗就知道，不支持改文件名，会影响咱们的缓存策略。
若是 public 中的静态资源没有加缓存，这样每次请求资源都会去请求服务器，形成资源浪费。
可是若是加了缓存，咱们每次更新静态资源就必须更新资源名称，不然浏览器仍是会加载旧资源。
因此，咱们在根目录新建 /assets 来放置静态资源，而且须要在 next.js 中配置 webpack。
根据官网，在根目录建立 next.config.js，自定义 webpack 配置。
图片
配置 image-loader
配置 file-loader。
安装 yarn add \--dev file-loader。
next.config.js
module.exports = {
webpack: (config, options) => {
config.module.rules.push({
test: /\.(png|jpg|jpeg|gif|svg)$/,
use: [
{
loader: 'file-loader',
options: {
// img 路径名称.hash.ext
// 好比 1.png 路径名称为
// _next/static/1.29fef1d3301a37127e326ea4c1543df5.png
name: '[name].[contenthash].[ext]',
// 硬盘路径
outputPath: 'static',
// 网站路径是
publicPath: '_next/static'
}
}
]
})
return config
}
}
直接使用 next-images
若是不想本身配置，也能够直接使用 next-images。
yarn add --dev next-images
next.config.js
const withImages = require('next-images')
module.exports = withImages({
webpack(config, options) {
return config
}
})
使用方法
<img src={require('./my-image.jpg')}/>
TypeScript
如今导入图像的文件仍是会报错，由于咱们使用了 TypeScript，而 Typescript 不知道如何解释导入的图像。
next-images 很贴心地准备了图像模块的定义文件。
因此，咱们只须要在 next-env.d.ts 文件中添加 next-images 类型的引用就好啦。
/// <reference types="next-images" />
更多的其余文件
本身找到 loader，而后配置 next.config.js，或者看看有没有封装成 next 插件。
这些属于 webpack 的范围，你们能够本身探索。这篇文章就不啰嗦了。
Next.js API
到如今为止，咱们的 index 和 posts/first-post 都是 HTML 页面。
但实际开发中咱们须要请求 /user、 /shops 等 API，它们返回的内容是 JSON 格式的字符串。在 Next.js 中怎么实现呢？
使用 Next.js 的 API 模式。
使用 Next.js API
demo
API 的默认路径为 /api/v1/xxx，咱们新建一个测试接口 demo.ts 。
在 api 目录下的代码只运行在 Node.js 里，不会运行在浏览器中。
demo.tsx
// ts 就是加上了类型
import {NextApiHandler} from 'next';
const Demo:NextApiHandler = (req, res) => {
// 其余的操做和 js 同样
res.statusCode = 200;
res.setHeader('Content-Type', 'application/json');
res.write(JSON.stringify({name: '狗子'}));
res.end();
};
export default Demo;
访问 http://localhost:3000/api/demo，获得数据。
posts
接下来咱们完成一个正式博客 API，posts 接口。
首先准备博客文件，根目录下建立 markdown 文档，写入几篇 md 格式的博客。
而后咱们借助 gray-matter 从 md 文件中解析数据。
lib/posts.tsx 这个文件导出 JSON 数据。
import path from "path";
import fs, {promises as fsPromise} from "fs";
import matter from "gray-matter";
export const getPosts = async () => {
const markdownDir = path.join(process.cwd(), 'markdown');
const fileNames = await fsPromise.readdir(markdownDir);
const x = fileNames.map(fileName => {
const fullPath = path.join(markdownDir, fileName);
const id = fileName.replace(fullPath, '');
const text = fs.readFileSync(fullPath, 'utf8');
const {data: {title, date}, content} = matter(text);
return {
id, title, date
}
});
console.log('x');
console.log(x);
return x;
};
搞定了数据，下面就简单多了，posts API 接口直接从上面的代码中获取数据，而后返回给前端便可。pages/api/posts.tsx
import {NextApiHandler} from 'next';
import {getPosts} from 'lib/posts';
const Posts: NextApiHandler = async (req, res) => {
const posts = await getPosts();
res.statusCode = 200;
res.setHeader('Content-Type', 'application/json');
res.write(JSON.stringify(posts));
res.end();
};
export default Posts;
ps：Next.js 基于 Express，因此支持 Express 的中间件。若是有复杂的操做，能够借助 Express 中间件。
Next.js 三种渲染方式
下面咱们来作前端部分，用三种渲染方式实现。
客户端渲染
只在浏览器上执行的渲染。
也就是最原始的前端渲染方式，页面在浏览器获取到 JavaScript 和 CSS 等文件后开始渲染。路由是客户端路由，也就是目前最多见的 SPA 单页应用。
缺点
但这种方式会形成两个问题。一是白屏，目前解决方法是在 AJAX 获得相应以前，页面中先加入 Loading。二是 SEO 不友好，由于搜索引擎访问页面时，默认不会执行 JS，只能看到 HTML，看不到 AJAX 请求的数据。
代码
pages/posts/BSR.tsx
import {NextPage} from 'next';
import axios from 'axios';
import {useEffect, useState} from "react";
import * as React from "react";
type Post = {
id: string,
id: string,
title: string
}
const PostsIndex: NextPage = () => {
// [] 表示只在第一次渲染的时候请求
const [posts, setPosts] = useState<Post[]>([]);
const [isLoading, setIsLoading] = useState(false);
useEffect(() => {
setIsLoading(true);
axios.get('/api/posts').then(response => {
setPosts(response.data);
setIsLoading(false);
}, () => {
setIsLoading(true);
})
}, []);
return (
<div>
<h1>文章列表</h1>
{isLoading ? <div>加载中</div> :
posts.map(p => <div key={p.id}>
{p.id}
</div>)}
</div>
)
};
export default PostsIndex;
访问 http://localhost:3000/posts/BSR，若是网络很差，白屏时间很长。
由于数据原本不在页面上，经过 ajax 请求后渲染到页面上。
文章列表都是前端渲染的，咱们称之为客户端渲染。
静态页面生成（SSG） Static Site Generation
咱们作的博客网站，其实每一个人看到的文章列表都是同样的。
那为何还须要在每一个人的浏览器上渲染一次呢？
能不能直接在后端渲染好，浏览器直接请求呢？
这样的话，N 次渲染就变成了 1 次渲染，N 次客户端渲染变成了 1 次静态页面生成。
这个过程就叫作动态内容静态化。
优缺点
这种方式能够解决白屏问题、SEO 问题。
但这种方式全部用户请求的内容都同样，没法生成用户相关内容。
代码：getStaticProps 获取 posts
显然，后端最好不要经过 AJAX 来获取 posts。
咱们的数据就在文件夹里面，直接读取数据就能够，不必发送 AJAX。
那么，应该如何获取获取 posts 呢？
使用 Next.js 提供的方法 getStaticProps 导出数据，NextPage 的 props 参数会自动获取导出的数据。
具体来看看代码吧：
SSG.tsx
import {GetStaticProps, NextPage} from 'next';
import {getPosts} from '../../lib/posts';
import Link from 'next/link';
import * as React from 'react';
type Post = {
id: string,
title: string
}
type Props = {
posts: Post[];
}
// props 中有下面导出的数据 posts
const PostsIndex: NextPage<Props> = (props) => {
const {posts} = props;
// 先后端控制台都能打印 -> 同构
console.log(posts);
return (
<div>
<h1>文章列表</h1>
{posts.map(p => <div key={p.id}>
<Link href={`/posts/${p.id}`}>
<a>
{p.id}
</a>
</Link>
</div>)}
</div>
);
};
export default PostsIndex;
// 实现SSG
export const getStaticProps: GetStaticProps = async () => {
const posts = await getPosts();
return {
props: {
posts: JSON.parse(JSON.stringify(posts))
}
};
};
访问 http://localhost:3000/posts/SSG，页面访问成功。
前端怎么不经过 AJAX 获取数据？
posts 数据咱们只传递给了服务器，为何在前端也能打印出来？
咱们来看看此时的页面：
如今前端不用 AJAX 也能拿到 posts 了，直接经过 __NEXT_DATA__ 获取数据。这就是同构 SSR 的好处：后端数据能够直接传给前端，前端 JSON.parse 一会儿就能获得 posts。
getStaticProps 静态化的时机
在开发环境，每次请求都会运行一次 getStaticProps，这是为了方便咱们修改代码从新运行。
而在生产环境，getStaticProps 只在 build 时运行，这样能够提供一份 HTML 给全部用户下载。
来体验下生产环境吧，打包咱们的项目。
yarn build
yarn start
打包以后，咱们获得三种类型的文件：
-
λ (Server) SSR 不能自动建立 HTML（等会再说）
-
○ (Static) 自动建立 HTML (发现你没用到 props)
-
● (SSG) 自动建立 HTML + JSON (等你用到 props)
建立出了这三种文件：posts.html = posts.js + posts.json
-
posts.html 含有静态内容，用于用户直接访问 -
post.js 也含有静态内容，用于快速导航（与 HTML 对应） -
posts.json 含有数据，跟 posts.js 结合获得页面
那为何不直接把数据放入 posts.js 呢？显然，是为了让 posts.js 接受不一样的数据。
当咱们展现每篇博客的时候，他们的样式相同，内容不一样，就会用到这个功能了。
小结
-
若是动态内容与用户无关，那么能够提早静态化。 -
经过 getStaticProps 能够获取数据，静态内容 + 数据（本地获取）就获得了完整页面。代替了以前的 静态内容+动态数据（AJAX获取）。 -
静态化是在 yarn build 的时候实现的 -
优势 -
生产环境直接给出完整页面 -
首屏不会白屏 -
搜索引擎能看到页面内容（方便 SEO）
服务端渲染（SSR)
若是页面跟用户相关呢？这种状况较难提早静态化。
那怎么办呢？
-
要么客户端渲染，下拉更新 -
要么服务的渲染，下拉 AJAX 更新(没有白屏
优势
这种方式能够解决白屏问题、SEO 问题。能够生成用户相关内容（不一样用户结果不一样）。
代码
和 SSG 代码基本一致，不过使用的函数换成 getServerSideProps。
写一段代码，显示当前用户浏览器是什么。
import {GetServerSideProps, NextPage} from 'next';
import * as React from 'react';
import {IncomingHttpHeaders} from 'http';
type Props = {
browser: string
}
const index: NextPage<Props> = (props) => {
return (
<div>
<h1>你的浏览器是 {props.browser}</h1>
</div>
);
};
export default index;
export const getServerSideProps: GetServerSideProps = async (context) => {
const headers:IncomingHttpHeaders = context.req.headers;
const browser = headers['user-agent'];
return {
props: {
browser
}
};
};
getServerSideProps
不管是开发环境仍是生产环境，都是在请求到来以后运行 getServerSideProps。
回顾一下 getStaticProps，看看他们的区别。
-
开发环境，每次请求到来后运行，方便开发 -
生产环境， build 时运行
参数
-
context，类型为 NextPageContext -
context.req/context.res 能够获取请求和响应 -
通常只须要用到 context.req
SSR 原理
最后咱们来看看 SSR 究竟是怎么实现的。
咱们都知道 SSR 是提早渲染好静态内容，这些静态内容是在服务端渲染，仍是在客户端渲染的？
具体渲染几回呢？一次仍是两次？
参考 React SSR 的官方文档
推荐 在后端调用 renderToString() 的方法，把整个页面渲染成字符串。
而后前端调用 hydrate() 方法，把后端传递的字符串和本身的实例混合起来，保留 HTML 并附上事件监听。
以上就是 Next.js 实现 SSR 的主要方法，也就是后端会渲染 HTML, 前端添加监听。
前端也会渲染一次，以确保先后端渲染结果一致。若是结果不一致，控制台会报错提醒咱们。
总结
-
建立项目 npm init next-app 项目名 -
快速导航 <Link href=xxx><a></a></Link> -
同构代码：一份代码，两端运行 -
全局组件： pages/_app.js -
全局 CSS：在 _app.js 里 import -
自定义 head：使用 组件 -
Next.js API：都放在 /pages/api 目录中 -
三种渲染的方式：BSR、SSG、SSR -
动态内容 术语：客户端渲染，经过 AJAX 请求，渲染成 HTML。 -
动态内容静态化 术语：SSG，经过 getStaticProps 获取用户无关内容 -
用户相关动态内容静态化 术语：SSR，经过 getServerSideProps 获取请求 缺点：没法获取客户端信息，如浏览器窗口大小 -
静态内容 直接输出 HTML，没有术语。
篇幅有限，更多可前往 https://github.com/Maricaya/nextjs-blog-1
回复“加群”与大佬们一块儿交流学习~
点击“阅读原文”查看 80+ 篇原创文章
本文分享自微信公众号 - 前端自习课（FE-study）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。