使用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刷新頁面的時候再重複這個過程。
步驟
首先釐清實現流程步驟。
最簡單的步驟：
- 獲取數據源
- 構建前端頁面
- 部署
其實就是簡單的三步。
數據源獲取
首先是數據源的獲取。
找到github.com api地址。
依照步驟
- 申請user token
- 找到對應的api
- (直接用api 前端query)(得到所有數據 自身根據數據做query)
這裏選擇了後者，因爲考慮到文件內容量一般不會特別大。
動手能力強的人，一般第一步不用跟步驟。
所以第二步開始。
我們這裏選用的是v4 版本的graphql api。
我挺喜歡graphql的。
- 查詢定義方便。
- 前後端可以用一套query 模版。
- 反正都是初次接觸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的話，建議使用動態路由去做佈署啦。
完整佈署後的demo地址
本文只是提供操作思路。具體實現還請翻看代碼。