乐趣区

使用nextjs结合GITHUB-ISSUE实现博客

jiezi

使用 next.js 结合 GITHUB ISSUE 实现博客。

起因

。。。。起因是因为在某网站看到有一些类似实现。打算自己也做个 side-project。

习惯性的对自己做的 side-project 做一些描述性的语句，不做具体，而提供思路。

next 简单的快速上手很快，基本没有什么曲线

可能只是需要了解服务端常见知识即可。

渲染。

我们常说 SSR 也就是服务端渲染。那对应的服务端渲染，自然有客户端渲染。

类似 SPA 就是客户端渲染。

首先从 router 来讲起。我们知道前端 router 自从有了 HTML5 API 以后也可以进行 router 功能。

hash 模式 OR history 模式。

两种模式的不同也只是在于 hash mode 对于 服务端 hashchange 也是一个 path
而 history mode 对于服务端 history push 可能对应的是另一个 asset path

所以一般需要对服务器做路径的匹配以导向对应资源。

而更多的应用采用的是简单的同构实现。

server render 做首屏或者 seo 优化，然后生命周期数据都继续在前端处理。refresh 刷新页面的时候再重复这个过程。

步骤

首先厘清实现流程步骤。

最简单的步骤：

  1. 获取数据源
  2. 构建前端页面
  3. 部署

其实就是简单的三步。

数据源获取

首先是数据源的获取。

找到 github.com api 地址。
依照步骤

  1. 申请 user token
  2. 找到对应的 api
  3. (直接用 api 前端 query)(得到所有数据 自身根据数据做 query)
    这里选择了后者，因为考虑到文件内容量一般不会特别大。

动手能力强的人，一般第一步不用跟步骤。

所以第二步开始。

我们这里选用的是 v4 版本的 graphql api。

我挺喜欢 graphql 的。

  1. 查询定义方便。
  2. 前后端可以用一套 query 模版。
  3. 反正都是初次接触 next 了，也不妨初次再接触 github 的 v4 api。

首先 REST API 是需要数据对应接口，http 方法决定操作，query 决定结果。操作幂等。

这里用 GraphQL 第一步，我们是需要找到 endpoint 入口节点。
用来接受并解析验证执行查询。

我们找到 repositoryConnection 利用这个连接找到所有 nodes 相关联信息即可。

学习 GraphQL 需要了解 nodes, connection, edge 基本概念

首先我们要获取所有 total 的数据源。

query {repository(owner:"ZWkang", name: "Start-Learning-React") {
    issues(orderBy: {
      direction: DESC,
      field: CREATED_AT
    }, first:1){totalCount}}
}

拿到 totalCount 以后用来去换取所有的 issue Data 源。

issues data query 可以自己试着写一下。

拿到以后就写入文件啦。

当然你也可以对数据源做一遍筛选。你喜欢都可以。

构建前端页面。

这里 next 其实我也不是用的很深。

以下列举一些我遇到的问题：

1. 自定义 server

首先是 server 端的 server start

你可以选择自定义得去处理请求，然后精确得控制路由 

app.prepare().then(() => {})

thenable 里面你甚至可以使用现有类库进行 router 操作。

2. 注意部署运行环境

要注意部署环境是 node 端还是 no server 端。

如果是 no server 端，例如 now publish 这些静态文件服务器。请使用动态路由进行处理。

原理是根据 router 在 build 的时候即进行处理。

3. 运行预处理 css/sass 等的话需要在 next.config.js 中自行配置环境

配置方式与 webpack 配置大同小异。

4. 可以利用 next/head 自定义生成 html 文档 head 部分内容

5. next/link 的使用。

link 是更强大的 router，处理封装了 as 属性，prefetch 方法等。

prefetch 默认行为是在 mouseover 的时候进行 prefetch 操作。prefetch 是在生产模式对资源的获取。

next/link 组件可以进行的具体操作参见文档内容

6. router 的问题。

之前我是用 server => page, 在 page 内处理 query 的。

后来用 now 布署频繁调试，发现自定义 server path 在 now server 上并不能用，看 issue 建议使用动态路由。

详情请看这篇文档

还有 router 会进行两次 render，在最后也是在上面文档发现了一个注意点。

Note: Pages that are statically optimized by automatic prerendering will be hydrated without their route parameters provided (query will be empty, i.e. {}). After hydration, Next.js will trigger an update to your application to provide the route parameters in the query object. If your application cannot tolerate this behavior, you can opt-out of static optimization by capturing the query parameter in getInitialProps.

next 会对页面组件进行一次路由的预渲染处理，所以 query 会为空。如果要取消这种行为可以使用 getInitialProps 方法。

后来在组件加 getInitialProps 果然就 disabled 这种情况了。

7. 利用动态 import 实现代码块切片。

服务端渲染可以让我们有一个好处就是 可以更颗粒化地处理 某个页面实际需要的内容块，从而优化加载速度。

利用 next/dynamic

由于我们这里使用的是一次性抓取的数据块。（其实可以区分多个数据块，对应页面获取对应数据块其实也可以，体积也较少。）

但是这里考虑到我的数据量还是很小的缘故，所以直接对原来的代码做切分。

articleList 组件 与 Article 组件分别用来做获取数据的异步块。

这样以来，首文件的大小就从 100K 降低到了 20K。WOW 真的是太棒了

布署

布署可以使用 node 端布署，自行架设服务器，用 pm2 等之类的进程管理 run server.js 即可。

如果使用 now 的话，建议使用动态路由去做布署啦。

now cli 地址

完整布署后的 demo 地址

  • demo 地址
  • github 地址

本文只是提供操作思路。具体实现还请翻看代码。

退出移动版