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

使用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 地址

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