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

本文只是提供操做思路。具體實現還請翻看代碼。