ブログをある程度最適化したので、その際のショートメモ。[前回](/post/migration-wordpress-nextjs-contentful-vercel)の続編のようなものです。記事にするほどでもないのですが忘却録として。以下のパッケージを利用してSSGしています。

- Next.js v10.0.5
- Contentful v8.1.6
- Theme UI v0.4.0-rc.14

## Theme UI

### スタイル方法を混合させない

Theme UIとstyled-jsxを混合させると、バッティングしない部分でも影響が出る模様。styled-jsxでbodyの`word-break`を定義していたのですが、本番環境のページリロード前後で結果が異なることがあった。Bodyへのグローバルスタイルは、素直にthemeの`styles.root`に定義するのが良いようです。

### passHref

next/linkには`passHref`を割り当てる。Theme UIでこれをつけない場合、アンカー要素の`href`が取り除かれ、SEOでも影響を受けます。これはEmotionなどjsx pragmaを利用するライブラリのソリューションとして[ドキュメント](https://nextjs.org/docs/api-reference/next/link#if-the-child-is-a-custom-component-that-wraps-an-a-tag)に記載されています。Theme UIはEmotionをベースにしたミニフレームのため、これに従います。

## page props

Next.js v9ではprefetch時のレスポンスにHTMLが乗っていましたが、 v10ではページpropsが単独JSONで乗っています。また、動的ルートのchunkも別途取得します。以下は公式チュートリアルのサンプルをv9とv10でコンパイルした比較です。

![v9-and-v10](//images.ctfassets.net/mmh9uyfw68qp/4dOFXmynPBarYjzEdy8p8g/29c19bcb32564607623f801f15e882ac/v9v10.png)

ページ遷移は高速になりますが、多くのページ内リンクがある場合はJSONの量も増えます。そこで`prefetch={false}`を設定し、滅多に読み込まれないリンクは事前ロードをさせないようにするのが良いようです。この場合、リンクにマウスカーソルが乗ったときにpropsとなるJSONがロードされます。

## 重たいコンポーネント

ボトルネックになるのがコードハイライト。Theme UIには[@theme-ui/prism](https://theme-ui.com/packages/prism)も用意されていますが、自分はカスタマイズ目的で[react-syntax-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter)を利用しています。jsxをサポートするにはPrismを使う必要があるのですが、これはサイズが相当大きい。そこでハイライトが必要な言語セットだけを読み込むようにしました。

```jsx
import { PrismLight as SyntaxHighlighter } from "react-syntax-highlighter";
import nord from "react-syntax-highlighter/dist/esm/styles/prism/nord";

// サポートしたい言語
import jsxx from "react-syntax-highlighter/dist/esm/languages/prism/jsx";
import javascript from "react-syntax-highlighter/dist/esm/languages/prism/javascript";
import json from "react-syntax-highlighter/dist/esm/languages/prism/json";
import php from "react-syntax-highlighter/dist/esm/languages/prism/php";
import css from "react-syntax-highlighter/dist/esm/languages/prism/css";
import bash from "react-syntax-highlighter/dist/esm/languages/prism/bash";
import markdown from "react-syntax-highlighter/dist/esm/languages/prism/markdown";

// 必要な言語を登録
SyntaxHighlighter.registerLanguage("jsx", jsxx);
SyntaxHighlighter.registerLanguage("javascript", javascript);
SyntaxHighlighter.registerLanguage("json", json);
SyntaxHighlighter.registerLanguage("php", php);
SyntaxHighlighter.registerLanguage("css", css);
SyntaxHighlighter.registerLanguage("bash", bash);
SyntaxHighlighter.registerLanguage("markdown", markdown);

// コードブロック
const CodeBlock = ({ language, value }) => {
  return (
    <SyntaxHighlighter language={language} style={nord}>
      {value}
    </SyntaxHighlighter>
  );
};
```

Next.js 10ではdist/esm以下のファイルを利用しようとするとビルドエラーが起こるため、トランスパイラの設定が必要です。[next-transpile-modules](https://www.npmjs.com/package/next-transpile-modules)をインストールし、以下のようなファイルを配置します。

```javascript
// next.config.js
const withTM = require("next-transpile-modules")(["react-syntax-highlighter"]);
module.exports = withTM();
```

一先ず完了ですが、**ページをリロードすると強調が狂う・本番環境で動作しない**等の[不具合](https://github.com/react-syntax-highlighter/react-syntax-highlighter/issues/263)が発生することがあります。hydrationが原因だそうです。

この場合、PrismLightではなくPrismAsyncLightを使うのが手っ取り早い。こちらは`code`を先にレンダリングし、コード内で必要とされる言語ファイルを判断して必要分だけ非同期でロードしてくれます。サイズは若干増えますが、レンダリングブロック時間を減らすこともできます。

```jsx
import { PrismAsyncLight as SyntaxHighlighter } from "react-syntax-highlighter";
```

また、Next.jsのnext/dynamicはSSRでなくとも`ssl:false`を渡すと、動的にコンポーネントをインポートすることもできます。

## 画像の遅延ロード

next/imageで画像を遅延読み込みすることがきますが、遅延だけが目的ならば現状は[react-lazy-load](https://www.npmjs.com/package/react-lazy-load)の方が安定しているように思えます。`fill`を指定しない限り、高さや幅の指定が必須なのもやや扱いづらい。

以上。1記事のサイズ500KB前後・低速回線でも読み込み500ms〜1sに抑えられるようになりました。他にもいくつかありますが、このブログ固有な面もあるのでここまでにしておきます。

Next.jsで作成したブログを最適化した際のメモ。

Next.jsブログの最適化

ブログをWordPressからNext.js+Contentful+Vercelへ移行しました。他者が見て参考になるかはわかりませんが、頭に残ってることを書いときます。WordPressは長年プラグインにほぼ頼らず細かい部分も自分でコードを書いていたのですが、それらのメンテにギブしたというのが移行の背景です。単純に使いづらくなったのもありますが。

## Next.js

SSGをしたかったので、この分野で強いGatsbyと悩みました。Next.jsは頻繁に仕様が変わるのがネックなのですが、それでも後方互換を大事にしているのとサードライブラリの充実度があり今回採用に至りました。

## Theme UI

スタイル設定にはTheme UIを使用しました。Theme UIはEmotion+MDX+Typography.jsを組み合わせたミニフレームワークです。外部から読み込むmarkdownへのスタイル設定時に、グローバルスコープの汚染を回避できるのが好みです。

Next.js 10ではJSX Pragmaが従来の方法では動作しないため、以下に書き直す必要がありました。利用しているバージョンは、0.4.0-rc.14です。

```jsx
/** @jsxRuntime classic */
/** @jsx jsx *
```

また、Firefoxでは開発時にのみ"Warning: Prop className did not match."がコンソールに表示されます。Next.jsのSSGは開発時はSSRになるため、そのCSSが挿入されていないことが原因と思われます。Material UIは[ServerStyleSheets](https://material-ui.com/guides/server-rendering/)でこの問題に対処できるようになっています。Theme UIが利用しているEmotionも[SSR時のソリューション](https://emotion.sh/docs/ssr)を用意していますが、自分の環境ではうまくいきませんでした。開発時のみ出る警告のため、現状は放置することにしました。

## Contentful

ContentfulはAPIベースのヘッドレスCMSです。日本語未対応ですが、稼働実績と無料枠があるので選択しました。ContentfulのAPIはWebアプリケーション内で利用する**Content Delivery API - CDA**とコンテンツ管理を行う**Content Management API - CMA**があります。どちらのAPIもプログラム内からだけではなくcurlでの呼び出しもできます。CDAの利用方法は以下のようなインスタンスを作成し操作を行います。

```jsx
const client = require("contentful").createClient({
  space: process.env.CONTENTFUL_SPACE_ID,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
});
```

コンテンツを取得するときには主に`getEntries()`というメソッドを使います。オプションで取得件数やソートなどが制御できます。件数はlimitキーで指定できますが、このメソッドは一度に最大1000件までしか取得できないという点に注意が必要です。ソート順はorderキーで制御でき、デフォルトは昇順。降順にするには、値の先頭にハイフンをつける。例えば`order: "-fields.publishedDate"`のような感じ。

各コンテンツの作成日付はsys.createdAtに存在していますが、これはあくまでContentful内で作成された日付であるため、前述のようなpublishedDateのようなフィールドをContent Model内に作成するのをお勧めします。特に既存のコンテンツをContentfulにインポートするようなケースの場合は、このような独自フィールドがないとインポートした日付すべてがsys.createdAt便りになるため、ソートなどで不便です。

一方、CMAは外部からContenfulのコンテンツの書き込みや読み込みができるため、後述するWordPressの移行時に利用しました。こちらのOAuth tokenは発行時しか確認することができないので取扱いに注意。

## WordPressから記事のインポート

Contentfulの記事本文はmarkdown形式を採用したいため、既存のWordPressの記事本文をHTMLからmarkdownに変換する必要がありました。まずWordPress標準のエクスポートでexport.xmlを書き出しておき、[wordpress-export-to-markdown](https://github.com/lonekorean/wordpress-export-to-markdown)を使ってローカルに記事を一括DLします。このライブラリは`npx wordpress-export-to-markdown`で対話形式で進行します。例えば以下のような構造で書き出しができます。

```bash
.
├── /2018
│   ├── /article-1
│   │   ├── index.md
│   │   └── /images
│   │       ├── android.jpg
│   │       └── ios.jpg
│   ├── /article-2
│   │   └── index.md
│   └── /article-3
│       ├── index.md
│       └── /images
│           └── linux.png
├── /2019
└── /2020
```

年の下に各記事のディレクトリを作成し、その中に記事がindex.mdで書き出されます。記事中に画像がある場合は、imagesというフォルダが生成されて中に画像が配置されます。マークダウンファイルの画像パスはこのローカル画像フォルダを参照します。

記事のタイトルはフォルダ名になるのですが、フォルダ名として利用できない記号は省略されます。また、フォルダ名はURLエンコードされているため、日本語などの2バイト文字が含まれる場合は別途デコードが必要でした。自分はnode環境で反復させて`decodeURI(dirname)`しました。ただし、記事のタイトル自体はindex.md内のFront-matterに投稿日と一緒に記載されているため、これを[gray-matter](https://www.npmjs.com/package/gray-matter)などを使って参照できます。

```markdown
title: "Next.js 9.3の変更点"
date: "2020-03-14"
------------------
ここに本文
```

GatsbyやMDXで利用する場合はこのまま必要なメタデータを使えば移行完了になります。今回は更にContentfulにエクスポートが必要なので、ここでCMAを利用しました。CMAはCDAとは別のアクセストークンが必要になるため、Contentfulでトークンを作成しておきます。

外部から記事の投稿に使うメソッドは`createEntry`です。Contentful modelにもよりますが、例えば１件挿入する場合は以下のようになります。自分の場合は６つのフィールドがあり、CategoryのみReference型になっています。Reference型の場合はtypeをlinkにして参照するコンテンツのIDを指定します。

```javascript
client.getSpace("<your-spaceid>").then((space) => {
  space
    .getEnvironment("master")
    .then((enviroment) => {
      enviroment.createEntry("blogPost", {
        fields: {
          title: { "ja-JP": "test-title" },
          slug: { "ja-JP": "test-slug" },
          description: { "ja-JP": "test-description" },
          body: { "ja-JP": "test-body" },
          publishedDate: { "ja-JP": "2020-12-01" },
          category: {
            "ja-JP": {
            	sys: {
              	type: "link",
              	linkType: "Entry",
              	id: "<your-category-id>",
            	},
            },
          },
        },
      });
    })
    .then((entry) => console.log(entry))
    .catch(console.error);
});
```

上記は値がハードコーティングされていますが、実際は先に取り出した記事の本文などの情報を配列に入れ、`Promise.all()`の中でインポートしました。尚、CMAは１秒あたり10件、1時間あたり36000件といったレートリミットが設けられているため、`setTimeout`で遅延させるなどの工夫が必要です。この部分は[wp-to-contentful](https://github.com/jonashcroft/wp-to-contentful)を参考にしました。面倒なら参照先のコードに全部任せて移行しても問題ないと思います。

同様に画像アセットもインポートできます。1件だと以下のような感じです。

```javascript
async function uploadFile(title, file, description ="demo") {
  var fileData = {
    fields: {
      title: { "ja-JP": title, },
      description: { "ja-JP": description },
      file: {
        "ja-JP": {
          contentType: file.contentType,
          fileName: file.fileName,
          upload: file.url,
        },
      },
    },
  };

  const fileobj = await client
    .getSpace("<your-space-id>")
    .then((space) => space.getEnvironment("master"))
    .then((enviroment) => enviroment.createAsset(fileData))
    .then((asset) => asset.processForAllLocales())
    .then((asset) => asset.publish())
    .then((asset) => asset.fields.file)
    .catch(console.error);

  return fileobj;
}
```

## インラインSVG

Next.jsでインラインSVGを取り扱う1番簡単な方法は、[airbnbのプラグイン](https://github.com/airbnb/babel-plugin-inline-react-svg)です。まず`yarn add --dev babel-plugin-inline-react-svg`でインストールします。そのあと.babelrcを編集します。

```json
{
  "presets": ["next/babel"],
  // 以下を追加
  "plugins": ["inline-react-svg"]
}
```

Next.js v10はインラインSVGで絶対パスは解決できないようです。babel-plugin-module-resolverというライブラリを入れれば解決できるそうですが、こだわりがなければ参照パスで十分です。ちなみにNext.jsのbaseUrlの設定も機能しませんでした。

```jsx
import Profile from "../assets/profile.svg";

<Profile width={48} height={48} />
```

## サイトマップ

ホスト先はVercelを利用しています。GitHubリポジトリとプロジェクトを接続することで、Vercelはプロジェクトで使用されているフレームワークを判別して規定のコマンドを実行してくれます。規定コマンドを上書きするにはVercelのBuild & Development Settingsで変更できます。ここにpostbuildはありませんが、package.jsonに記述したpostbuildはmainブランチにマージしたときに行われる自動ビルド時でも実行してくれるようです。SSG後にサイトマップを出力するには[next-sitemap](https://github.com/iamvishnusankar/next-sitemap)が便利で、前述のpostbuildを利用して書き出します。

```json
"scripts": {
	"postbuild": "next-sitemap"
}
```

next-sitemap.jsを配置するのを忘れないように。

```javascript
module.exports = {
  siteUrl: "https://www.the2g.com",
  generateRobotsTxt: true,
};
```

ちなみに生成されるsitemap.xmlはgitignoreに入れておきます。

## 環境変数

### Vercelの独自環境変数

Vercelはデプロイ時にランダムなURLを生成して割り振ります。例えば"my-site-xxxxx.vercel.app"のような形式。このURLはデプロイ後に生成されますが、この値をコード内で動的に取得したい場合はVERCEL_URLという環境変数を使うとアクセスできます。ただし、環境変数はデフォルトでは無効になっていて、有効化するにはプロジェクトのSettingsからEnviroment VariablesのAutomatically expose System Enviroment Variablesという項目にチェックを入れます。これでコードでは`process.env.VERCEL_URL`という環境変数で動的なURLを取得できます。注意点は、プロジェクトに独自ドメインを割り当てた場合でも、VERCEL_URLで取得されるURLは自動生成される方のURLであり、独自ドメインははないという点です。

その他にも[色々な環境変数](https://vercel.com/docs/environment-variables#system-environment-variables)が用意されています。

### Next.jsの環境変数

Next.js 9.4からenvファイルを利用した環境変数がサポートされています。本番や開発環境に応じて環境変数を使い分けることができます。これを利用したときにリポジトリに含めることのできない環境変数（Contentfulのシークレットなど）は`env.local`のようなlocal付きenvファイルに記述します。

本番用にはVercelのSettingsにあるEnviroment Variablesに同名の名前で定義します。ここで定義しておくと、GitHubと連携後にコードをプッシュして自動ビルドしてくれるときもこの環境変数を利用してくれます。

## RSS

RSSフィードは[feed](https://github.com/jpmonette/feed)を使い生成しました。指定フォーマットに従ってURLなどの各種値を設定するだけなので定義は簡単です。このライブラリは１つのインスタンスでXML2種とJSON1種のファイルを作成できます。Next.jsの場合はpublic/rssのようなフォルダに書き出すようにしておけば、ビルド後はルートにrss/feed.xmlといった感じで配置されます。フィードの生成タイミングはindexページの`getStaticprops()`内で行いましたが、フィードの生成をAPIルートに置いてビルドフックのようなもので呼び出すのが本来スマートなのかなと思います。

一般的なRSS Readerは記事の取得タイミングが数十分から一時間以上と思ったより長く、さらには開発環境では取得の動作確認ができないなど、中々面倒でした。

## ドメイン移行

ドメインは引き続き現状のものを使っていきたいので移行手続きを行いました。Vercelのプロジェクトの設定のDomainsを選択して既存のドメインを入力すると、A RecordとNameserversが表示されるのでメモしておきます。

自分の場合、ドメインは[スタードメイン](https://www.star-domain.jp?ref=NAqqz4ih)で取得しています。管理ページからネームサーバーとDNSレコードを編集できるフォームが用意されているため、上記でメモした値に書き換えれば問題なく動作しました。

## リダイレクト

旧ブログの記事URLとインポートした記事のURLが異なるためリダイレクトさせます。Vercel or Next.jsどちらからでも設定ができるようです。Vercel側で設定すると、フレームワーク（今回の場合Next.js）を問わずリダイレクトさせることができますが、開発環境では`yarn dev`でリダイレクトは動作しません。この場合は`vercel dev`を使えば動作します。Next.js側でリダイレクト設定をすれば前者でも動作しますが、今回はVercel側でリダイレクトの設定をすることにしました。

まず、古いURLと新URLの一覧を次のようなフォーマットでGoogle SpreadSheetsに作成します。これはCMAで記事を書き出すときにマッピングしておいたデータを加工して作りました。

![route-data](//images.ctfassets.net/mmh9uyfw68qp/7IDLV74T5NJ9Bpqx0c9hWQ/c198cb54cd25e6412f78a7d8984fa1c8/route-data.png)

これを[Export Sheet Data](https://workspace.google.com/marketplace/app/export_sheet_data/903838927001)というアドオンを使い以下のようなJSONで書き出します。`name`というキーがありますが、この値は実際は使っていません。単に後から確認がしやすいためです。

```json
[
  {
    "name": "Spotify Web Player not working in Vivaldi",
    "source": "/2479",
    "destination": "/spotify-web-player-not-working-in-vivaldi"
  },
  {
    "name": "PhotoShopで全ピクセルをガイドで囲む",
    "source": "/2503",
    "destination": "/surround-every-pixel-with-a-guide-using-photoshop"
  },
  ...
]
```

これを使ってリダイレクト用の設定ファイルを書き出すスクリプトを作成します。

```javascript
const fs = require("fs");
const data = require("./data/route-data.json");

// source: 移転前のパス
// destination: 宛先
// permanent: 永続(308)はtrue, 一時的(307)はfalse
let routes = data.map((item) => {
  return {
    source: item.source,
    destination: `/post${item.destination}`,
    permanent: true,
  };
});

let redirects = {
  redirects: routes,
};

let newdata = JSON.stringify(redirects, null, 2);
fs.writeFileSync("vercel.json", newdata);
```

これでvercel.jsonが書き出せるので、プロジェクトルートに配置すれば完成です。

```json
{
  "redirects": [
    {
      "source": "/2479",
      "destination": "/post/spotify-web-player-not-working-in-vivaldi",
      "permanent": true
    },
    {
      "source": "/2503",
      "destination": "/post/surround-every-pixel-with-a-guide-using-photoshop",
      "permanent": true
    },
    ...
  ]
}
```

とりあえず記事の移行と投稿ができるところまでが目先の目標だったので、最適化はまだしていません。時間ができたときにでも修正していこうかなと思ってはいます。

Next.js+Contentful+Vercelへ移行した際に頭に残っていることなど。

WordPressからNext.js+Contentful+Vercelへの移行

遅れながらNext.js 9.4の変更点に触れていきます。基本的に公式に沿っていますが、割合した部分および多少コードの補足を加えています。

## Fast Refresh

Next.jsはホットリロードが搭載されていましたが、9.4では新たに[react-refresh](https://github.com/facebook/react/tree/master/packages/react-refresh)が搭載されました。react-refreshはホットリロード同様に自動リロード機能を持っていますが、加えてコードの変更前後で**アプリケーションの状態を維持することができます**。

![Fast Refresh Demo](//images.ctfassets.net/mmh9uyfw68qp/2b1fCGApzAuZxFowv0oucE/3b1b6fd78a6dcb8a486f2111e6752a53/demo.gif)

スタイル、マークアップ、イベントハンドラ、エフェクトで状態維持がサポートされているようです。エラー位置を正確に出力してくれるなど利便性も上がっています。

## 環境変数

9.3以前の環境変数は`next.config.js`を用いてましたが、9.4からは以下も可能になりました。

- `NEXT_PUBLIC_`で始まるインライン変数
- `.env`ファイルでカスタム環境変数を追加する

### インライン変数

Next.jsはアプリケーション内で`NEXT_PUBLIC_`で始まる環境変数をインライン化（数値を値に置き換える）するようになりました。例えばページ内に以下が記述されているとします。

```jsx
<p>hello, {process.env.NEXT_PUBLIC_NAME}</p>
```

`NEXT_PUBLIC_NAME=mda yarn dev`と実行すると、`<p>hello, mda</p>`となります。

インライン変数はJavaScriptのバンドルに含まれるため、機密情報の埋め込みに適していません。

### .envファイルによる環境変数

プロジェクトのルートに`.env`ファイルを置くと、環境変数として公開することができます。ただし、環境変数はNode.js環境でのみ動作し、クライアント（ブラウザ）のJavaScriptバンドルには含まれません。変数を含めたい場合は、前述したようにインライン変数にする必要があります。

```shell
NEXT_PUBLIC_NAME='mda'
API_VALUE=10
```

上記の`.env`ファイルの場合、クライアントコードでは`API_VALUE`にアクセスできませんが、`NEXT_PUBLIC_NAME`はクライアントのコードでアクセスできます。

```jsx
// pages/index.js
function Home() {
  return (
    <>
      {/* ブラウザでアクセス可能 */}
      <p>{process.env.NEXT_PUBLIC_NAME}</p>
      {/* ブラウザでアクセス不可 */}
      <p>{process.env.API_VALUE}</p>
    </>
  )
}

export default Home
```

以下では、Node.js環境のため`API_VALUE`変数が動作します。

```jsx
export default function Home({ post }) {
  return (
    <>
      <section id={post.id}>
        <h1>{post.title}</h1>
        <p>{post.body}</p>
      </section>
    </>
  )
}

export async function getServerSideProps(context) {
  const id = process.env.ID;
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
  const post = await res.json();
  return { props: { post } }
}
```

`.env`ファイルは実行時の環境に応じて、複数のファイルを用意できます。以下の`[enviroment]`には、`develop`, `production`, `test`が明記できます。実行時において`next dev`は**development**、`next build`と`next start`は**production**と見なされます。

- .env
- .env.local
- .env.\[enviroment\]
- .env.\[enviroment\].local

`local`がつくものは変数の上書きに使います。`local`なし版はリポジトリの管理対象に入れ、`local`版は`.gitignore`に記述するようです。このため、後者が機密情報を保管するのに適しています。また、適用される優先順位もあり、上記では下にいくほど優先順位が高くなります。

例えば先程のサンプルにおいて、以下の3つのファイルを用意したとします。

```javascript
// 便宜上、3つのファイルを1箇所に記述しています

// .env
ID=1

// .env.development
ID=5

// .env.development.local
ID=10
```

これを`next dev`すると`ID=10`が使用されます。`next build`後に`next start`とするとproductionになりますが、production用の環境ファイルはないため、`.env`の`ID=1`が使用されます。

## 絶対インポート

`jsconfig.json`に`baseUrl`を設けると、絶対インポートが可能になりました。`.`はルートディレクトリを指しています。

```json
// jsonconfig.json(TypeScriptの場合はtsconfig.json)
{
  "compilerOptions": {
    "baseUrl": "."
  }
}
```

例えば長々しい`../../../components/button`も以下で解決されます。

```jsx
import Button from 'components/button';
```

### エイリアス

`baseUrl`に加えて`paths`オプションを使うと、エイリアスも設定できるようになります。

以下のようなディレクトリ構造を想定します。

```shell
(root)/
├── components/
│   └── nest/
│       ├── partsA.js
│       └── partsB.js
└── pages/
    └── index.js
```

通常、`index.js`からpartsAとpartsBをインポートするには、以下のようになります。

```jsx
import PartsA from '../components/nest/partsA';
import PartsB from '../components/nest/partsB';
```

`jsconfig.json`に`paths`を追加してみます。

```json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/parts/*": [
        "components/nest/*"
      ]
    }
  }
}
```

`@/parts/*`に`components/nest/*`というパスをマップしたため、以下が可能になります。

```jsx
import PartsA from '@/parts/partsA';
import PartsB from '@/parts/partsB';
```

VSCodeなどを使用していると、パス部分で補完が適用されるようにもなっています。

## Web Vitals Reporting

Google Chromeが提供し出したWeb VitalsがNext.jsに組み込まれました。公式にあるように`pages/_app.js`に`reportWebVitals`というメソッドを配置し、メトリックを計測できます。

```jsx
// pages/_app.js
export function reportWebVitals(metric) {
  console.log(metric);
}

function MyApp({ Component, pageProps }) {
  return <Comopnent {...pageProps} />
}

export default MyApp;
```

例えば、トップページにアクセスすると、以下が出力されました。

```json
{
   "id":"1590175632294-1421296618188",
   "name":"Next.js-hydration",
   "startTime":537.2850000003382,
   "value":15.414999999848078,
   "label":"custom"
}
{
   "id":"1590175868092-9818419920942",
   "label":"web-vital",
   "name":"FCP",
   "startTime":452.3850000005041,
   "value":452.3850000005041
}
{
   "id":"1590175868092-9037373988752",
   "label":"web-vital",
   "name":"TTFB",
   "startTime":0,
   "value":19.775000000663567
}
```

`name`に記載されているのがネットワークリソースの応答性の指標として使用される測定値名です。

**FCP**はFirst Contentful Paintの略で、ブラウザがDOMのコンテンツの最初のビット（テキストや画像など）がレンダリングされるポイントを示します。**TTFB**はTime To First Byteの略で、サーバへの接続が要求された後、最初のバイトが利用者のブラウザに到達するまでの時間を示します。**Next.js-hydration**は、Next.jsが実際のドメインデータを埋め込んでいく段階のことだと思われます。そして、実際の参考値には、`startTime`や`value`を利用します。

このように[Next.jsの固有値](https://nextjs.org/docs/advanced-features/measuring-performance#custom-metrics)も含め、各種メトリックをキャプチャすることが容易になりました。

## その他の変更点

- Incremental Static Regeneration - 静的コンテンツを再レンダリングさせるメソッド。現在betaバージョンのため割合しますが、今後よく利用されそうな機能になると思われます
- 組み込みfetchメソッドの改善 - ブラウザおよびNode.js環境で同じfetchメソッドが利用できるようになりました。[node-fetch](https://github.com/node-fetch/node-fetch)などのモジュールを導入する必要がなくなります
- Sassの設定オプション - `next.config.js`でSassのオプション設定ができるようになりました
- ログ出力 - ログの出力が再設計されました

Next.js 9.4は後方互換が保たれているため、特に問題なく移行できるはずです。


Next.js 9.4の変更点について簡単にまとめています。

Next.js 9.4の変更点

先日Next.js 9.3がリリースされました。いくつか機能が追加されましたが、特に開発に影響を与えると思われるのが、`getStaticProps`, `getStaticPaths`, `getServerSideProps`の3つの関数です。

Next.jsはSSR(Server Side Rendering)とSSG(Static Site Generation)の2つのビルド方式があります。SSRはサーバ側で実行されるためクライアントへのJavaScript送信量を抑えられるといった利点がありますが、TTFBは遅くなります。SSGは制約こそありますがHTMLがビルド時に生成されるため、高速でSEOに強いなど近年人気があります。

Next.js 9.0では[Automatic Static Optimization](https://nextjs.org/blog/next-9#automatic-static-optimization)が導入され、ページ初期化時にブロック要件がなければページはSSGされます。しかし、フェッチしたデータがコンテンツになるようなブロックの発生するページも静的に書き出せればより便利です。それを成すのが`getStaticProps`と`getStaticPath`です。一方、`getServerSideProps`は明示的にSSRを行います。

⚠以降コードは可能な限り公式を模範しています。データフェッチ部分のみ[JSONPlaceholder](https://jsonplaceholder.typicode.com/)を使い実際に動作するコードに書き直しています。

## getStaticProps（SSG）

非同期で`getStaticProps`をエクスポートするとSSGが行えます。 まずは簡易なページでSSGを試してみます。最初にページナビゲーションができるトップページを作成します。

```jsx
// pages/index.js

import Link from "next/link";

const Home = () => (
  <>
    <ul>
      <li>
        <Link href="/">
          <a>Home</a>
        </Link>
      </li>
      <li>
        <Link href="/blog">
          <a>Post</a>
        </Link>
      </li>
    </ul>
    <h1>Home</h1>
  </>
);

export default Home;
```

`getStaticProps`内でフェッチを行うBlogコンポーネントを作成します。

```jsx
// pages/blog.js

// getStaticPropsはnode環境のため、ブラウザ標準のfetchは使用できない
import fetch from "node-fetch";

function Blog({ posts }) {
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

export async function getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts
    }
  };
}

export default Blog;
```

これをビルドすると以下になりました。

![ssg-result1](//images.ctfassets.net/mmh9uyfw68qp/3noEAaeV67rTKiTJg9tZr9/8ecc5e19305d858e4ae1b73d8c53c61f/ssg-result1.png)

`/blog`は静的生成（SSG）として書き出されています。

## getStaticProps + getStaticPaths（動的ルーティング）

次は`getStaticProps`で動的ルーティングされたページのSSGを試してみます。まずBlogコンポーネントでルーティング用のリンクを設けます。

```jsx
// pages/blog.js

import fetch from "node-fetch";
import Link from "next/link";

function Blog({ posts }) {
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>
          <Link href="/posts/[id]" as={`/posts/${post.id}`}>
            <a>{post.title}</a>
          </Link>
        </li>
      ))}
    </ul>
  );
}

export async function getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts
    }
  };
}

export default Blog;
```

`href`がディレクトリ上のパスで、`as`がURLバーに表示されるパス。前者のブランケットで囲んだ部分が`as`の動的に変更される`{$post.id}`に対応しています。

次に`pages`に`posts`ディレクトリを作成し、中に`[id].js`を作成します。

```jsx
// /pages/posts/[id].js

import fetch from "node-fetch";

const Post = ({ post }) => (
  <section key={post.id}>
    <h1>{post.title}</h1>
    <p>{post.body}</p>
  </section>
);

// (1) SSG対象となるパスのリストを定義
export async function getStaticPaths() {
  // 全件数取得
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();

  // パスのリストを作成
  const paths = posts.map(post => `/posts/${post.id}`);
  return { paths, fallback: false };
}

// (2) 実際にSSGする関数
// paramsには上記pathsで指定した値が入る（全件ではなく1postずつ）
export async function getStaticProps({ params }) {
  const res = await fetch(
    `https://jsonplaceholder.typicode.com/posts/${params.id}`
  );
  const post = await res.json();

  return { props: { post } };
}

export default Post;
```

これで`build`および`dev`ともに実行できます。開発環境下の場合はSSGで書き出されているわけではないので、各postsページに飛ぶときはデータフェッチが起こります。

![ssg-dev](//images.ctfassets.net/mmh9uyfw68qp/3fcsT8AGrEn62U11OgHTIX/c9c159b3d42145e0b0978133b51d6dd7/ssg-dev.gif)

以降、要点を解説します。

### getStaticPaths

SSGの対象にしたいパスを指定するのが`getStaticPaths`の役目です。戻り値にパスの一覧とフォールバック（後述）を指定します。今回パスは`/posts/1`〜`/posts/100`までを指定したいため、`/posts`で取得できる100件分をフェッチして、結果を`map`で回してパスを生成します。

```jsx
const paths = posts.map(post => `/posts/${post.id}`);
```

`paths`は以下のようになります。

```javascript
[
  '/posts/1',
  '/posts/2',
  '/posts/3',
  '/posts/4',
  ...
  '/post/100'
]
```

これが書き出す動的ルーティングのパスです。ドキュメントだと、`{ params: { id: 1} }`のような形式で返すように書かれていますが、配列にパスのリストを渡すだけで問題ないようです。`getStaticProps`関数が受け取る引数を見るとそれがわかります。

```jsx
export async function getStaticProps(ctx) {
    console.log(ctx);
    ...
}
```

例えば`http://localhost:3000/posts/3`をリクエストすると、以下が出力されます。

```javascript
{ params: { id: '3' } }
```

`getStaticProps`が受け取る引数は`getStaticPaths`から受け取る`paths`に対応するオブジェクトで、ドキュメント通りのフォーマットになっています。

#### fallback

`getStaticPaths`の戻り値にパスと一緒に指定する論理値です。これは指定したパス以外がリクエストされた場合に、ページをどう処理するかを決めます。

- false: 返されないパスは404にする
- true: 返されないパスはリクエストされたときに生成する

ページが大量にあってビルドに時間をかけたくない場合や、ビルド時に読み込むパスをすべて把握できない場合は`true`にします。後者はSSRを使う方が便利なケースが多いので、`false`を指定することが多いと思います。

### getStaticProps

最初に説明した`getStaticPaths`です。ここでは先程指定したパスを使って個々のpostデータをフェッチしています。取得したデータを`props`経由でコンポーネントに渡すには、波括弧でラップする必要があるようです。

```jsx
return { props: { post } };
```

あとは、Postで受け取るデータをレンダリングすると、それがSSGされます。

ビルドすると、`/posts/[id]`の100件分のページがSSGで生成されているのが確認できます。

![ssg-result2](//images.ctfassets.net/mmh9uyfw68qp/65Me2bnl3Oj2ESzpiHhiox/b34b1cb86f2258168f1e7a03fde289e9/ssg-result2.png)

## getServerSideProps（SSR）

非同期の`getServerSideProps`関数をエクスポートすると、サーバサイドレンダリング（SSR）されます。この関数は従来の`getInitialProps`と使用方法や役割は大体同じです。引数にはcontextオブジェクトが格納され、直接URLを入力したときだけではなく、`next/link`を使いページ遷移したときもフェッチがあればそれを行います。

先程SSGとして記述した動的ルートをSSRで書き直してみます。

```jsx
// /pages/posts/[id].js

import fetch from "node-fetch";

const Post = ({ post }) => (
  <section key={post.id}>
    <h1>{post.title}</h1>
    <p>{post.body}</p>
  </section>
);

export async function getServerSideProps(context) {
  // e.g. { id: 1 }
  const { id } = context.query;
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
  const post = await res.json();

  return { props: { post } };
}

export default Post;
```

戻り値を`props`で渡すときはSSGと同様に、波括弧でラップが必要です。

上記は`getInitialProps`で以下のように記述できていました。

```jsx
import fetch from "node-fetch";

const Post = ({ post }) => (
  <section key={post.id}>
    <h1>{post.title}</h1>
    <p>{post.body}</p>
  </section>
);

Post.getInitialProps = async context => {
  const { id } = context.query;
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
  const post = await res.json();

  // Wait!, Look!, Attention!
  return { post };
};

export default Post
```

`getInitialProps`は後方互換を持っているので、この書き方も現状は問題なく動作します。

## その他の変更点

その他、Next.js 9.3ではSassのサポート強化、ヘッドレスCMSとの変更をリアルタイムに反映できるプレビューモード、404ページの自動静的最適化などが追加されました。

非推奨になる機能はないので、Next.jsのバージョンアップ自体は問題なく行なえます。


Next.js 9.3で追加されたgetStaticProps, getStaticPaths, getServerSidePropsの解説になります。

Next.js 9.3の変更点

[SWR](https://github.com/zeit/swr)はZEITによるデータ取得ライブラリです。Next.jsだけではなく、React単体でも使用できます。今回は、このライブラリの必要性に触れてみます。

## SWRを使う理由

SWRの主な用途はキャッシュとボイラープレートの排除です。従来のReactアプリケーションで外部リソース（API）の取得を行う場合、以下のようなコードを目にします。

```jsx
const [data, setData] = React.useState([]);

useEffect(() => {
    fetch("https://some-api/users")
    .then(response => response.json())
    .then(data => {
        setData(data);
    });
}, []);
```

データ取得を行うたび、この定型文（+エラー処理）が出現します。

例えば、階層の異なるコンポーネントで`data`を利用したいとします。`props`を介したり、Reduxやcontextで解決することはできますが、コードは複雑になります。「利用するコンポーネントで再リクエストすりゃいいじゃん」と思うかもしれませんが、現状のReactには**状態のキャッシュというものが存在しない**ため、再び同コストが必要になります。

SWRはこういった問題点を解決します。

## useSWR

使用するのは、`useSWR`です。これは、データ保存をするフックです。

```jsx
const { data, error } = useSWR(key, fetcher, options);
```

- data - API取得結果
- error - エラー内容
- key - ユニークなキーを指定。REST APIならば、エンドポイントURLです。
- fetcher - リクエストを行う関数。要件はpromiseを返すということだけ。
- options - [オプション](https://github.com/zeit/swr#options)

例えば、以下のようなコードになります。

```jsx
const fetcher = (...args) => fetch(...args).then(res => res.json());

function App() {
    const { data, error } = useSWR("https://your-api/any", fetcher);

    if (error) return <p>Error</p>
    if (!data) return <p>Loading</p>

    return (<SomeComponents data={data} />);
}
```

エラー処理を含めてもコードがシンプルです。また、別のコンポーネントから`useSWR`で同じキーでデータ取得を行うと、キャッシュからデータを取り出してくれます。更にリソース元が更新されている場合は、対応するすべてのコンポーネントが再レンダリングされます。コンポーネントツリーは常に最新データと同期しているということです。

ささっと書きましたが、実はこのキャッシュ周辺の仕様は難しいです。無知ながら掻い摘むと、SWRでは同じキーでリクエストを行うと、`dedupingInterval`（デフォルトは2秒）内では再リクエストをせずキャッシュを使用します。この期間を過ぎた後だと、再リクエストが起こりキャッシュが再検証されます。このインターバル値は、`useSWR`のオプションから変更が可能です。詳しく知りたい場合は、Stale-While-Revalidateでググりましょう。SWRはこの仕様に沿っています。

これで`useSWR`はマスターです。しかしブログ記事としては物足りないため、次にSWRを使った超簡単なデモアプリでも作成してみます。SWRの他のAPIにも触れます。

## Demo Application

MTG（マジックザギャザリング）のカード一覧を表示するという簡易なWebアプリを作成します。素晴らしいことに[公式](https://docs.magicthegathering.io/)がAPIを公開しているので、これを利用させて頂きます。

以降は、Reactの開発環境が整った段階からの解説になります。コードは[CodeSandbox](https://codesandbox.io/s/react-swr-mtg-2pqex)にあります。

まずはパッケージをインストールします。

```shell
yarn add swr
```

queries.jsというファイルを作成し、fetcher関数を定義します。

```jsx
export const fetcher = (...args) => fetch(...args).then(res => res.json())
```

App.jsxを以下のようにします。

```jsx
import React from "react";
import { SWRConfig } from 'swr';
import Card from './components/Card';
import Cards from './components/Cards'

// GlobalSetting
const queryConfig = {
  suspense: true,
};

const App = () => {
  const [activeCard, setActiveCard] = React.useState(null);

  return (
    <>
      <h1>MTG Card List</h1>
      <div className="container">
        <SWRConfig value={queryConfig}>
          <React.Suspense fallback={<div>Loading...</div>}>
            {activeCard ? (
              <Card
                activeCard={activeCard}
                setActiveCard={setActiveCard}
              />
            ) : (
              <Cards setActiveCard={setActiveCard} />
            )}
          </React.Suspense>
        </SWRConfig>
      </div>
    </>
  );
};

export default App;
```

`activeCard`に値があれば`Card`を表示し、なければ`Cards`を表示しているだけです。実際に入る値は、カードの`id`値になります。

`SWRConfig`はグローバルに`useSWR`のクエリオプションを設定するものです。要は全体で使う共通オプションです。ラップした下位のコンポーネントで`useSWR`を使う際には、その設定が適用されます。ここでは`suspense: true`を設定しています。これは、フェッチ時に`React.Suspense`を利用するオプションです。これがない場合、特に処理を記述しなければデータ取得中に画面が真っ白になります。

次はCards.jsxです。ここで`useSWR`を使い、カード一覧の取得と表示をします。

```jsx
import React from "react";
import useSWR from "swr";
import { fetcher } from "../util/queries";
import Button from "./Button";

export default function Cards({ setActiveCard }) {
  const { data, error } = useSWR(
    "https://api.magicthegathering.io/v1/cards?pageSize=20",
    fetcher
  );

  if (error) return <div>error occured: {error.message}</div>;
  // if (!data) return <div>Loadin now</div>;

  return (
    <>
      {data.cards.map(card => (
        <article key={card.id} className="item">
          <h3>{card.name}</h3>
          <p>{card.text}</p>
          <p>
            <small>{card.flavor ? card.flavor : "no flavor"}</small>
          </p>
          <Button
            onClick={() => {
              setActiveCard(card.id);
            }}
          >
            view
          </Button>
        </article>
      ))}
    </>
  );
}
```

コメントされている`if`文がありますが、これは前述した`React.Suspense`を有効にしているため、この1行が実行されることはないという意味です。suspenseを無効にした場合は、このようなコードが必要になります。

次は、単一カードを表示するCard.jsxです。

```jsx
import React from 'react';
import useSWR from 'swr';
import { fetcher } from '../util/queries';

import Button from './Button';

export default function Card({ activeCard, setActiveCard }) {
  const { data, error } = useSWR(
    `https://api.magicthegathering.io/v1/cards/${activeCard}`,
    fetcher,
  );

  if (error) return <div>error occured: {error.message}</div>;

  const { card } = data;
  return (
    <article>
      <h3>{card.name}</h3>
      <figure>
        <img src={card.imageUrl} alt={card.name} />
      </figure>
      <Button onClick={() => setActiveCard(null)}>Back</Button>
    </article>
  );
}
```

`activeCard`には選択したカードの`id`が入っており、`useSWR`でフェッチするURLに埋め込まれて一意のキーとなります。残りのコードは、取得したデータを使ってカード情報を表示しているだけです。

最後はButton.jsxです。

```jsx
import React from "react";

export default function Button({ children, onClick }) {
  const handleClick = e => {
    onClick(e);
  };

  return (
    <>
      <button onClick={handleClick}>{children}</button>
    </>
  );
}
```

ボタンをクリックしたときに`activeCard`の値をリセットするだけのコンポーネントです。

## 実行結果

カードを選択するとフェッチが起こります。初回は時間がかかりますが、一度リクエストすると結果がキャッシュに残り、再びカードを選択するときはキャッシュからデータが取り出されます。

![result-1](//images.ctfassets.net/mmh9uyfw68qp/34x2D9pdj3yuAdIiMPWzwl/f1f76d5ab4a032a6f67065d1dc241273/result-1.gif)

この例ではユニークキー（URL）が決まった後に取得先の内容が変更されることはないため意味はありませんが、`dedupingInterval`を超えるとデータの再取得があり、キャッシュは再検証されます。2秒内だと検証リクエストはありません。上の画像はわかりやすいように、`dedupingInterval`を10秒にしています。検証リクエストが行われていないのが確認できます。なんにせよキャッシュで高速化します。SWRの方針は、古いものでも表示する内容があれば、まずはそれを表示しよう！です。

尚、カード画像自体はあくまで演出というか、ブラウザ自体の画像キャッシュです。画像データそのものがSWRのキャッシュに入っているというわけではありません。

## おわりに

SWRはデータ取得における定型文の排除とキャッシュ機能を提供してくれます。いずれReactにキャッシュ機能が搭載されるかもしれませんが、それまでは利用しておきたいライブラリだと思いました。

Next.jsブログの最適化

WordPressからNext.js+Contentful+Vercelへの移行

Next.js 9.4の変更点

Next.js 9.3の変更点

React+SWR