react-markdownのメジャーアップデートv6がきており、v5からいくつか仕様が変更されていた。既存コードを書き直す必要があったので、その際の変更点などを残しておく。環境は次のとおりです。

- react-markdown（6.0.0）
- react-styntax-highlight（15.4.3）
- Next.js（10.1.3）
- theme ui（7.0）

## 主要な変更点

`source`が廃止され、`children` propsになった。

```jsx
<Markdown>{`source`}</Markdown>
```

`renderers`が`components` propsに変更された。これに伴いコンバートさせるコンポーネント名もいくつか変更された。例えば`image`と`imageReference`は両者とも`img`になった。

```jsx
<Markdown
  components={{
    code: CodeBlock,
   	img: BlockImage,
  }}>
  {...}
</Markdown>
```

`allowDangerousHtml`が削除された。同様のことを行うには[rephy-raw](https://github.com/rehypejs/rehype-raw)を使う必要があるらしい。

## コードブロック

[react-syntax-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter)を併用すると、v5のままでは動作しなくなった。

ちなみにv5ではコードブロックは以下のようにしていた。

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

const CodeBlock = ({ language, value }) => {
  const styles = { margin: "16px 0" };
  return (
    <SyntaxHighlighter language={language} style={nord} customStyle={styles}>
      {value}
    </SyntaxHighlighter>
  );
};
```

v5ではCodeBlock関数で受け取るpropsは次のようなものだった。コードブロック（複数行）のみ捜査され、インラインコードは対象外。

```json
{
  children: "",
  language: "language-bash",
  node: object,
  value: "ls -la",
}
```

一方、v6ではコードブロックは次のようなpropsを受け取る。

```json
{
  children: "",
  className: "language-bash",
  node: object,
}
```

そしてv6はインラインコードも捜査され、以下のようなpropsを受け取る。

```json
{
	children: ["..."],
	inline: true,
	node: object,
}
```

まとめると

- v5の`className`がv6の`language`に対応
- v5の`value`がv6の`children[0]`に対応
- `className`はコードブロックのみに存在する
- `inline`はインラインコードにのみ存在する

### 公式のサンプル

公式にはコードハイライトの[サンプル](https://github.com/remarkjs/react-markdown#use-custom-components-syntax-highlight)が次のように記載されている。前述のようにコードブロックでは`className` propsが存在するため、これを使い出力を分岐させている。

```jsx
// 抜粋
const components = {
  code({node, className, ...props}) {
    const match = /language-(\w+)/.exec(className || '')
    return match
      ? <SyntaxHighlighter language={match[1]} PreTag="div" style={dark} {...props} />
      : <code className={className} {...props} />
  }
}

render(<ReactMarkdown components={components} children={markdown} />, document.body)
```

模範して自分のプロジェクトに組み込んでみると、動作はするが2点問題が起こった。

- コンソールにインラインエラーが出る
- コードブロック下部に空白ができる

#### コンソールのインラインエラー

開発ツールで以下のようなエラーが表示される。

> Warning: Received true for a non-boolean attribute inline.
> If you want to write it to the DOM, pass a string instead: inline="true" or inline={value.toString()}.

これは`inline`および`{...props}`が原因。カスタマイズしていないのなら、`<code className={className} />`にすればエラーは出ない。もしくはinlineを切り分け、以下のようにするといい。

```jsx
const components = {
  code({node, className, inline, ...props}) {
    const match = /language-(\w+)/.exec(className || '')
    return match
      ? <SyntaxHighlighter language={match[1]} PreTag="div" style={dark} {...props} />
      : <code className={className} {inline.toString()} {...props} />
  }
}
```

#### コードブロック下の空白

スタイルをリセットしても生じるため、暫し深みにはまった。

![codeblock](//images.ctfassets.net/mmh9uyfw68qp/5wOy5bhCQsKpMQfn9VC5ve/ffa89aa238bae29ec5fd6644c6623349/codeblock.png)

これはコードブロックの`children` propsの末尾に`"\n"`が追加されているのが原因。つまり余分な1行が生成されている。解決にはこの改行コードを削除する。

```jsx
<SyntaxHighlighter language={match[1]} style={dark} PreTag="div">
	{children[0].replace(/\n$/i, "")}
</SyntaxHighlighter>
```

このおせっかいはv5ではなかった。

### preの増殖

v5までは生成されるコードが`pre > code`だったが、v6では`pre > pre > code`になっている。1番上のpreはreact-markdownが生成しているもので、その下のpreはsyntex-hilighterが生成している。`preTag`でreact-syntax-highlighter側で生成されるpreをdivに変更させないと、二重preが出来上がってしまう。

```jsx
<SyntaxHighlighter PreTag="div" ... />
```

react-syntax-highlighterには、`customstyle`という最上位のpreのスタイルを上書きするpropsがある。v5まではこれ用いてコードブロック全体をラップするスタイルを設定できていたが、v6では前述のようにreact-markdownが生成したpreが最上位にあるため、親preにスタイルを適用させる方法がなくなっている。

このようにv6は、使い勝手が幾分悪くなっている印象を受ける。

react-markdown v5からv6の変更点を取り上げています。

react-markdown v6の変更点

ブラウザにデータを保存する方法にはいくつか種類があります。Web Storageやクッキー、そして今回触れるIndexedDBです。クッキーなどは保存できるサイズも小さくテキストしか扱えませんが、IndexDBはblobや構造化されたデータを扱うことができます。名前からわかるように、フロント側に用意された簡易なデータベースです。キーや条件による検索など、データに対して多様なクエリを実行することもできます。JSONベースのNoSQL型データベースを操作するAPIと考えればイメージが掴めるかと思います。IndexedDBは、Google KeepやDropboxなどで実装されているのが確認できます。

IndexedDBはドメインをまたぐことができないので、各々のWebサイト固有のデータになります。データベースはデータを格納するためにオブジェクトストアという仕組みを持ちます。オブジェクトストアに格納される各レコードはキーと値を持っており、実際に操作するのはこのオブジェクトストアへの操作が主となります。また、データベースはバージョン情報を持っており、データを更新するたびにバージョンを更新していく必要があります。

## Dexie

IndexedDBは仕様が思ったよりも難しく操作も煩雑になります。そこでよく利用されているラッパーに[Dexie](https://dexie.org/ "dexie")があります。最近、React用のフックが追加されたことを知ったので、これを使ってみることにします。フォームの入力値を保存して画面に表示する簡易なWebアプリ作成してみます。[ここで実際の動作及び最終コード](https://codesandbox.io/s/uselivequery-demo-vpgbx)を確認できます。

⚠ `useLiveQuery`フックは現状、dexie@3.1.0-alpha以上でないと利用できません。正式リリース後に仕様が変更になっている可能性もあります。また、ブラウザの設定によっては解説と挙動が異なることがあるかもしれません。このページで書かれているコードは、2021年3月時点で最新版の3.1.0-alpha.8の仕様に沿っています。

### セットアップ

まず、必要なパッケージをインストールします。

```bash
yarn add dexie@3.1.0-alpha.8 dexie-react-hooks
```

今回の主役でデータベースを担当する`modles/db.js`を作成します。

```jsx
import Dexie from "dexie";
import { populate } from "./populate";

export const db = new Dexie("myDB");
db.version(1).stores({ items: "++id,name" });

db.on("populate", populate);
```

`new Dexie("データベース名")`でデータベースを作成します。`db.version(バージョン).stores({ スキーマ })`でオブジェクトストア（IDBObjectStore）の作成とスキーマの定義をしています。ここでは主キーidとプロパティnameを持つitemsというオブジェクトストアを作成しています。主キーは省略することもでき、その場合は`, name`のように定義します。idに`++`というインクリメントがありますが、これはスキーマ構文といい`++`はオートインクリメントする主キーを意味します。他にもユニークキーを示す`&`などがあります。

IndexedDBのスキーマの定義はSQLとは異なり、すべてのプロパティ（SQLではカラム名）を定義する必要がなく、インデックスを作成したいプロパティのみを指定します。インデックスとは、オブジェクトストアに格納されているオブジェクトへの追加のパスのようなものです。このため、実際のレコードの挿入時はスキーマの定義時にない値も追加できます。blobのように大きなデータの場合はインデックスを作成する必要はなく、仮にスキーマで定義してしまうとパフォーマンスが低下します。

最後に、`db.on("populate", トリガー関数)`で初期化時のダミーデータを読み込みます。"populate"は、データベースがクライアントに存在せずストアを作成する必要があるときに一度だけ呼ばれます。この`on`メソッドの第一引数のイベントタイプには、他にも`ready`や`error`などが存在します。

### 初期化時のデータ

次に上記で定義しているpopulate関数を作成するため、`modles/populate.js`を作成します。

```jsx
import { db } from "./db";

export async function populate() {
  await db.items.bulkAdd([{ name: "dummy-A" }, { name: "dummy-B" }]);
}
```

データベースへの追加は`db.ストア名.bulkAdd(オブジェクト)`で行います。単一データの場合は、`add()`というメソッドも存在します。これらのメソッドはPromiseを返します。SessionStorageやクッキーは同期型でメインスレッドをブロックしますが、IndexedDBは非同期に実行するため、メインスレッドをブロックしません。

IndexedDBのすべての操作はトランザクション内で実行する必要があるのですが、Dexieは自動でトランザクションを開始してコミットしてくれます。今回は割合していますが、明示的にトランザクションを開始することもできます。

### フォーム

`src/Form.js`でフォームを作成します。

```jsx
import React from "react";
import { db } from "../models/db.js";
import { populate } from "../models/populate.js";

function Form() {
  const [name, setName] = React.useState("");

  const addItemDb = async e => {
    e.preventDefault();
    await db.items.add({
      name
    });
    setName("");
  };

  return (
    <div>
      <form onSubmit={e => addItemDb(e)}>
        <fieldset>
          <input
            type="text"
            placeholder="input name"
            value={name}
            onChange={e => setName(e.target.value)}
          />
          <button type="submit" disabled={!name.length > 0}>
            Add
          </button>
        </fieldset>
      </form>
    </div>
  );
}

export default Form;
```

重要なのはボタンクリック時に呼ばれるハンドラ関数内の`db.items.add()`だけです。このメソッドは先程書いたように単一データをストアに追加するメソッドです。ここではフォームの入力データを格納しています。

### リスト

次にデータベース内のデータを表示する`src/List.js`を作成します。

```jsx
import React from "react";
import { useLiveQuery } from "dexie-react-hooks";
import { db } from "../models/db.js";

const List = () => {
  // db.itemsが変更されたときにコンポーネントは再レンダリングされます
  const items = useLiveQuery(() => db.items.toArray(), []);

  // 読み込み中
  if (!items) return null;

  const removeItemDb = async id => {
    await db.items.delete(id);
  };

  const data = items.map(({ id, name }) => (
    <li key={id} onClick={() => removeItemDb(id)} aria-hidden>
      {id}: {name}
    </li>
  ));

  return (
    <div className="box">
      <h2>IndexedDB</h2>
      {data.length > 0 && <ul>{data}</ul>}
    </div>
  );
};

export default List;
```

ここでようやく`useLiveQuery`フックが登場します。このフックは優秀で、データベースが変更されたときにコンポーネントを再レンダリングしてくれます。第一引数は読み出すストアデータを指定し、第二引数に監視するパラメータを指定します。これは`useEffect`の第二引数と似ています。ここではitemsストアの全データが変数itemsに格納されます。あとはこのデータを`map`を使いレンダリングする要素を作成しているだけです。各レコードはidとnameを持つので、単にそれらを出力しています。

また、要素をクリックするとそのデータを削除できるように、削除用のハンドラ関数として`removeItemDb`を定義しています。idを受け取り、`db.items.delete(id)`で指定したIDのレコードを削除しています。idは主キーなので一意のレコードが削除されます。

### まとめる

最後に`App.js`を次のようにします。

```jsx
import React from "react";
import Form from "./Form";
import List from "./List";

import "./styles.css";

export default function App() {
  return (
    <div className="container">
      <Form />
      <List />
    </div>
  );
}
```

上記で読み込んでいるスタイルは次のようにしています。

```css
.container {
  max-width: 860px;
  margin: 1em auto;
  font-family: sans-serif;
}
.box {
  background-color: rgb(105, 202, 170);
  margin-top: 1em;
  padding: 2em;
}
li {
  padding: 0.5em;
}
ul li:hover {
  background-color: #fff;
}
label,
input,
button {
  font-size: inherit;
  padding: 0.2em;
  margin: 0.1em 0.2em;
  -moz-box-sizing: content-box;
  -webkit-box-sizing: content-box;
  box-sizing: content-box;
}
```

アプリを起動すると、ダミーデータが`id: name`の形式で2つ表示されるはずです。フォームに何か入力してAddボタンを押すとその内容がデータベースに追加され、その内容が下部に表示されます。同様にリストのデータをクリックするとデータベースからそのデータが削除され、画面からも削除されます。データはクライアントに保管されるため、ページをリロードしたりブラウザを再起動してページに再アクセスしても前回の状態が保持されています。

![result](//images.ctfassets.net/mmh9uyfw68qp/5Su83WmqglmPmns4HTEdDX/8da635b426c83bed37739ef6d714e4be/result.gif)

ここで重要なのは、データベースにデータを追加/削除しただけで画面にその内容が反映される点です。表示部分を担当している`List.js`を再確認してもらえればわかりますが、状態変数を変更したわけでもないのに、コンポーネントが再レンダリングされています。これを担ってくれているのが`useLiveQuery`です。

### リセット

オブジェクトストアのデータをリセットする機能を追加しましょう。ここで少し興味深い動作が確認できます。`Form.js`のForm関数内に以下のハンドラ関数を追加します。`db.items.clear()`はitemsオブジェクトストアを削除するという関数です。その後のpopulate関数は、初期化時に読み込んだダミーデータを再び呼び出しています。

```jsx
const resetDb = async e => {
  alert("オブジェクトストア[items]をリセットしました");
  await db.items.clear();
  await populate();
};
```

そして次のようなボタンを追加します。

```jsx
<button type="button" onClick={() => resetDb()}>
  Reset
</button>
```

実行後、Resetボタンを押してみます。一度ストアが削除され、再び初期化のダミーデータが表示されます。しかし、画面に表示されているidは1から始まっていません。少し不思議な感じがしますが、こういうものみたいです。RDBMSで歯抜けの主キーは埋めないのと似ているかもしれません。

![store-reset](//images.ctfassets.net/mmh9uyfw68qp/o2mk2BkKkdcNew84x8sY9/6e0af447e9617c725c9962f022d9ba60/store-reset.gif)

ダミーデータにid値を持たせておけばリセット後もidを固定することはできます。ただし、後から追加されるデータは影響を受けるため、あくまでダミーのみ固定したい場合に限ります。主キーがidでなければ問題ありません。

```jsx
export async function populate() {
  await db.items.bulkAdd([
  	{ name: "dummy-A", id: 1 },
  	{ name: "dummy-B", id: 2 }
  ]);
}
```

少し異なりますが、データベースを削除すればすべてが初期化されます。

```jsx
db.delete("myDB");
```

## おわりに

Dexieを使うとIndexedDBの操作が簡単になります。特に`useLiveQuery`フックはデータベース内の変更を捉え、コンポーネントを自動で再レンダリングしてくれるので便利です。

追伸、サンプルにカラーパレットのようなものを作成していたのですが、解説が長くなるのでお蔵入りしました。供養として[途中まで作成したもの](https://codesandbox.io/s/dexie-react-hooksswitch-theme-r0uhl)を置いておきます。

DexieのuseLiveQueryを使用して、ReactでIndexedDBを操作する方法です。

Dexie useLiveQuery入門

ブログをある程度最適化したので、その際のショートメモ。[前回](/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の変更点について簡単にまとめています。

.css-i80p35{color:var(--theme-ui-colors-primary);font-size:inherit;cursor:pointer;-webkit-text-decoration:none;text-decoration:none;}react-markdown v6の変更点

Dexie useLiveQuery入門

Next.jsブログの最適化

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

Next.js 9.4の変更点

react-markdown v6の変更点