## はじめに
フロントエンドにおいても、製品の品質を向上させ、維持していく上で、テストは必須と言えるほど重要になってきています(参考: <a href="https://roadmap.sh/frontend" target="_blank" rel="noopener noreferrer">Frontend Developer Roadmap</a>)。  
テストの状態を計測するよく使われる指標の一つとして、テストのカバレッジ率があります。  
フロントエンドのテストは、主に単体テスト、統合テスト（コンポーネントテスト）、E2Eテストに分けられます。  
Cypressでは基本的にこれらすべてを一元的に実装できるため、テストを書く上で便利です。  
ただ、CypressはJestやJestベースのPlarywrightと違って、標準ではカバレッジレポートを出力できません。  
特にNext.jsでは<a href="https://docs.cypress.io/guides/tooling/code-coverage" target="_blank" rel="noopener noreferrer">公式で紹介されている方法</a>そのままでは計測できなかったので、  
Next.jsとCypressを使ったサイトでテストカバレッジ率を計測する方法について、  
実際に検証しながら整理してみました。

※この記事では、Cypressの導入部分は省略します

## 全体の流れ
1. 計測のためのプラグインを追加する
1. package.json レポートのオプションを追加
1. Cypress の config に計測のための設定をを追加
1. Cypress の 共通設定部分にプラグインの読み込みを追加
1. Next.js の config にプラグインの記述を追加
2. テストを実行し、レポートを表示する

## 計測のためのプラグインを追加する
Cypressでカバレッジ率のタスクを実行するための **@cypress/code-coverage** と Next.jsでレポートを作成するための **swc-plugin-coverage-instrument** をインストールします。
```bash
npm i -D @cypress/code-coverage swc-plugin-coverage-instrument
```

## package.json レポートのオプションを追加
レポートに含めたいファイルや、含めたくないファイルがある場合、以下のように"nyc"の項目を追加して、オプションを指定します。

###### package.json
```diff
{
  "name": "example",
  ︙
  },
+  "nyc": {
+    "extension": [".ts", ".tsx"],
+    "include": ["pages/**/*.tsx", "src/**/*.ts", "src/**/*.tsx"],
+    "exclude": ["node_modules/**", "mock-data/**", "cypress/**", "**/*.cy.ts"],
+    "excludeNodeModules": true,
+    "excludeAfterRemap": true
+  }
}
```

## Cypress の config に計測のための設定を追加
cypress.config.ts へ以下のように、コードカバレッジを計測するための設定を追加します。

###### cypress.config.ts
```diff
import { defineConfig } from "cypress";
+ import codeCoverageTask from "@cypress/code-coverage/task";

export default defineConfig({
  env: {
    enableMock: true,
+    codeCoverageTasksRegistered: true
  },
  e2e: {
+    setupNodeEvents(on, config) {
+      codeCoverageTask(on, config);
+      return config;
+    },
    baseUrl: "http://localhost:3000"
  },
  component: {
    devServer: {
      framework: "next",
      bundler: "webpack"
    },
    defaultCommandTimeout: 6000,
+    setupNodeEvents(on, config) {
+      codeCoverageTask(on, config);
+      return config;
+    }
  }
});
```

## Cypress の 共通設定部分にプラグインの読み込みを追加
cypress/support/component.ts や cypress/support/e2e.ts に、  
プラグイン読み込みのコードを追加します。
###### cypress/support/component.ts | cypress/support/e2e.ts
```diff
+ import "@cypress/code-coverage/support";
```

## Next.js の config にプラグインの記述を追加
next.config.js のビルド設定部分にも、プラグインの記述を追加します。

###### next.config.js
```diff
const withImages = require("next-images");

module.exports = withImages({
  trailingSlash: true,
+  experimental: {
+    swcPlugins: [
+      ["swc-plugin-coverage-instrument", {
+        compact: false
+      }]
+    ],
+  },
});
```

## テストを実行して、レポートを表示する
これで、準備ができましたので、実際にテストを実行してレポートを表示してみます。

### テストを実行
テストの script は package.json で以下のように設定しているとします。
```diff
{
  ︙
  "scripts": {
    ︙
+    "cypress": "cypress open",
+    "cypress:e2e": "cypress run --e2e",
+    "cypress:component": "cypress run --component"
    ︙
  },
  ︙
}
```

コンポーネントテストを実行してみます。
```
npm run cypress:component
```
テストが終了すると、以下のディレクトリにファイルが生成されます。  
- coverage
- .nyc_output

coverage/lcov-report/index.html を表示すると、  
以下のようなレポートを確認できます。  
  
 ![](https://cont.sterfield.co.jp/uploads/report_gui_883931f06d.png) 

また、以下のようにコマンドを打つことで、概要を表示できます。
```bash
npx nyc report --reporter=text-summary 
```
  
 ![](https://cont.sterfield.co.jp/uploads/report_cl_7970bcc25b.png) 
状態、分岐、関数、行数など、色々な方向で評価してくれます。

## まとめ
Next.jsでは、バンドラーがSWCなため、公式ドキュメントに従って設定すると実行が難しいことがわかりました。  
ただ、調査を進めることで、レポートの取得が可能であることがわかりました。  
今後はこれを活用し、Next.jsとCypressを組み合わせて効果的なテスト運用を構築していく予定です。  
この組み合わせにおいては、準備が整えば手軽にテストレポートを取得でき、より効率的かつ信頼性の高い開発プロセスを構築できると考えています。  
今回の課題を克服することで、将来的なプロジェクトでの利用をスムーズに進めることが期待できます。  
Next.js ✖️ Cypressの組み合わせを最大限に活かし、テストの品質向上に貢献していきます。

## 参考リンク

- [Frontend Developer Roadmap](https://roadmap.sh/frontend)
- [Code Coverage | Cypress Documentation](https://docs.cypress.io/guides/tooling/code-coverage)
- [swc-plugin-coverage-instrument](https://github.com/kwonoj/swc-plugin-coverage-instrument?tab=readme-ov-file)

nino-eye.jpg

Next.jsとCypressを使ったWebアプリでテストのカバレッジ率を計測する

## はじめに
Reactでフロントエンドの開発を行う場合に、おそらく一度は誰でも状態管理に頭を悩ませるのではないでしょうか。  
2023年10月現在、Redux、React Hooks、zustand、そしてここで取り上げる Recoil、Jotai など、Reactの状態管理をするためのライブラリや方法は数多く存在ます。  
多くの開発者によりその使い方が模索・洗練されていますが、絶対的な正解というものは存在しません。  
故に、プロジェクトに導入する場合に、どれを選定するかで、とても迷う方は多いのではないでしょうか。  
このブログでは、私が状態管理のライブラリを選定するときに悩んだ内容から、案件の向き不向きについて考察し、ご紹介したいと思います。  

## まず Redux、zustand と Recoil、Jotai の違いについて
Redux は、Reactを作ったFacebookが提唱した[Flux](https://github.com/facebookarchive/flux/tree/main/examples/flux-concepts)というアーキテクチャをもとにした、初期から最も利用されている状態管理ライブラリです。  
Reactとは切り離して１つのストアに集約して管理するため、情報の流れが一方通行で辿りやすい特徴があります。WEBアプリ全体の一貫性を重視し、堅牢な作りにする場合、Reduxは有望な選択肢となります。  
しかしながら、Reduxは非同期通信を伴うような複雑な状態管理ではそのまま使うのはあまりにもコードが膨大になってしまうため、サードパーティのプラグインなどを導入することが現実的な選択肢となります。また、1つのストアで管理するため、コンポーネント単位でのカプセル化が苦手です。  
  
zustand はこのReduxの苦手な部分を補うことで、Reduxからの乗り換えが進んでいるライブラリです。  
基本的な思想はReduxと同じですが、Reduxで煩雑になるような記述をより簡潔に書くことができます。 
  
Recoil は Redux とは違う思想で、ストアを複数持ち、それぞれに対して別々のコンポーネントからアクセス可能です。ストアが一元管理されているReduxやzustandとちがい、コンポーネント単位でのカプセル化がしやすく、データとアプリ全体の結合を制限することに向いているので、柔軟性を重視するアプリに向いていると言えそうです。
ただ、複数のストアに別々のコンポーネントから双方向でアクセスできる特徴が故に、組み方によってはReduxと比べると情報の流れを辿りにくくなる可能性があることに注意が必要です。  
  
Jotai は Recoil をより簡潔に記述できるようにしたライブラリで、[npm trends](https://npmtrends.com/Jotai-vs-react-redux-vs-recoil-vs-zustand)を見ると、2023年10月現在、本家のRecoilを追い抜いています。  

## RecoilよりJotaiが向いている案件
RecoilとJotaiで同じ状態管理をするためのコードを比べてみましょう。
#### Recoil
```typescript
const exampleState = atom({
  key: "exampleState",
  default: 0
});
const exampleSelector = selector({
  key: "exampleSelector"
  get ({ get }) => `${get(exampleState)}個を選択中`
});
```
#### Jotai
```typescript
const exampleState = atom(0);
const exampleSelector = atom((get) => `${get(exampleState)}個を選択中`);
```
こうやって並べてみるとよく分かりますが、  
Jotaiの方が圧倒的にコード数が少なくなります。  
Recoilで用意されている機能の多くはJotaiでも利用できるので、よりシンプルに状態管理を行いたい場合は、  Jotaiが向いていると言えます。  
  
## JotaiよりRecoilが向いている案件
では、次の場合はどうでしょう。  
#### Recoil
```typescript
// Writable
const idState = atom({
  key: "idState",
  default: 1
});

// Read Only
const fetchState = selector({
  key: "fetchState",
  get: async ({ get }) => {
    const id = get(idState);
    try {
      const response = await fetch(`example.api.json?id=${ id }`);
      const json = await response.json();
      return json;
    } catch (error) {
      throw error;
    }
  }
});

// Writable (default value fetched)
const complexState = atom({
  key: "complexState",
  default: selector({
    key: "complexSelector",
    get: async ({ get }) => {
      const json = await get(fetchState);
      return {
        id: json.id,
        name: json.exampleName
      }
    }
  })
});
```
#### Jotai
```typescript
// Writable
const idState = atom(1);

// Read Only
const fetchState = atom(async (get) => {
  const id = get(idState);
  try {
    const response = await fetch(`example.api.json?id=${ id }`);
    const json = await response.json();
    return json;
  } catch (error) {
    throw error;
  }
});

// Writable (default value fetched)
const defaultComplexState = atom(async (get) => {
  const json = await get(fetchState);
  return {
    id: json.id,
    name: json.exampleName
  }
});
const overWrittenComplexState = atom(null as { id: number; name: stirng; });
const complexState = atom<number, [number], void>(
  async (get) =>
    (await get(overWrittenComplexState)) ||
    (await get(defaultComplexState)),
  (_get, set, update) => set(overWrittenComplexState, update)
);
```
このように初期値をフェッチしつつ、後からデータの上書きもできるようなストアを作ろうとするような複雑な処理をさせようとした場合、JotaiよりRecoilの方が分かりやすいコードになることがわかるかと思います（もっと上手な書き方があったらすみません）。  
また、フェッチしたデータをリセットできるようにする場合、  
  
#### Recoil
```jsx
const exampleState = atom({
  key: "exmapleState",
  default: 0
})
const ExampleComponent = () => {
  const [example, setExample] = useRecoilState(exampleState);
  const reseter = useResetRecoilState(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Recoilはatomに対してそのままuseResetRecoil()を使うことでリセット可能ですが、  
  
#### Jotai
```jsx
const exampleState = atomWithReset(0);
const ExampleComponent = () => {
  const [example, setExample] = useAtom(exampleState);
  const reseter = useResetAtom(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Jotaiでは、あらかじめreset用のutil（atomWithRest）を使ってatomを用意する必要があります。  
その他にも、Jotaiでは複雑な操作をしようとした場合に、Recoilと同様の操作をするためにより多くのutilを使ったり、helperを自前で用意しなければいけない場合に遭遇します。  
  
これらのことから、より複雑なデータ処理を扱うような使い方をする場合、Recoilの方が向いていると言えます。  

## まとめ
堅牢でアプリ全体を見通すことを優先するのであれば Redux。  
基本的な思想はReduxと同じだけど、よりシンプルに描きたいのであれば zustand。  
機能追加やコンポーネントの入れ替えが多いような柔軟性のあるアプリで、複雑なデータ管理が必要なら Recoil。  
柔軟性とシンプルさを重視するなら Jotai というのが、現時点での自分の選択基準でした。

## 参考リンク

- [Jotai](https://jotai.org/)
- [Recoil](https://recoiljs.org/)
- [Redux](https://redux.js.org/)
- [zustand](https://github.com/pmndrs/zustand)
- [npm trends: jotai vs recoil vs redux vs zustand](https://npmtrends.com/jotai-vs-recoil-vs-redux-vs-zustand)

20231006_1.png

Reactの状態管理ライプラリはRecoilとJotaiならどちらをえらべばいいか？

最近、WordPress以外のCMSへの移行の需要も広がりつつあるというお話を聞きます。  
CMSとして80%の圧倒的なシェアを持つWordPressですが、  
シェアの大きさゆえに攻撃の対象にもなりやすく、  
実際、攻撃を受けてセキュリティの被害に遭うことも少なくありません。  
また、多くの機能を実装できるため、実装次第で重くなりやすい特徴もあります。  
そういったこともあり、WordPressを使わないCMSへの移行を望む企業さんも増えているようです。  
   
その移行先として注目されているのが、ヘッドレスCMSと呼ばれる種類のCMSです。  
WordPressでは、コンテンツの管理とサイトのレンダリングを両方行います。   
一方、ヘッドレスCMSでは、コンテンツの管理のみを行い、サイトのレンダリングやジェネレートなどは別のサービスを利用して行います。  
そのため、サイトからコンテンツへの攻撃がされにくくなります。  
また、コンテンツの数が多くなってもサイトのレンダリングに直接影響しないため、表示速度を上げやすいメリットもあります。  
   
この記事でご紹介する「Strapi」は、Node.jsのヘッドレスCMSとしては人気があります。  
ヘッドレスCMSは多くのサービスが提供されていて、CMS選びに迷いますが、  
ホスティングサービスを利用しなければ無料で利用でき、  
Nodejsの環境があればローカルで始められるので、開発のハードルが低いのが大きな理由でしょうか。  
  
Strapiはコンテントタイプ（WordPressでいう投稿タイプやタクソノミー）フィールドを自由に構成でき、  
ユーザのロールなども管理でき、APIもRestAPIとGraphQLから選ぶことができるので、  
高い拡張性が特徴です。  
  
この記事では、Strapiでサイトを構築する１つの方法として、  
OSをUbuntu、WebサーバをNginx、サイトのジェネレートをNext.js、そしてCMSをStrapiで開発を始める方法を共有します。  
ここでは動作するまでのインストールに重点を置き、コンテンツの作成などは省略します。  
  
## 目次
1. <a href="#section1">UbuntuでNginxによるサーバを設定する</a>
2. <a href="#section2">Node.jsでNext.jsとStrapiの環境を準備</a>
3. <a href="#section3">Next.jsとStrapiでデータを連携する</a>

# UbuntuでNginxによるサーバを設定する
<a id="section1"></a>
## Nginxのインストール
参考にさせていただいたサイト: <a target="_blank" rel="noopener noreferrer" href="https://vpslife.server-memo.net/ubuntuserver2204_nginx_install/">【Ubuntu Server 22.04】Nginx公式サイトのリポジトリを使用してインストール  |  VPS Life</a>  
↑詳細はこちらのサイトが詳しいです。  
この記事ではざっくりと流れだけ触れていきます。 
  
### パッケージのインストール
```bash
$ sudo apt update
$ sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
```
  
### 署名鍵のインポートと確認
```bash
$ curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
 | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
$ gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg
```
  
正しくインポートされると以下が表示されます
```bash
pub   rsa2048 2011-08-19 [SC] [expires: 2024-06-14]
      573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
uid                      nginx signing key 
```

### リポジトリの追加とインストール
```bash
$ echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" \
 | sudo tee /etc/apt/sources.list.d/nginx.list
$ sudo apt update
$ sudo apt install nginx
```
### インストールの確認
nginxのインストールに成功すると、以下のコマンドでバージョンを確認できます。
```bash
$ nginx -v
```

## ufwによるファイアウォール設定とNginxでサーバの設定
### ufw によるファイアウォール設定
そのままサーバを開設すると、セキュリティ的に良くないので、ufwを使って開放するポートを制限します。  
参考にさせていただいたサイト: <a target="_blank" rel="noopener noreferrer" href="https://mynotebook.h2np.net/post/1519">ufwの最小限設定について – とりあえずノートがわりに書いてます</a>  
  
**ufwを設定するときは、いきなり実行するとSSH接続ができなくなってしまうので、  
まずは、```ufw status``` を実行して、```Status: inactive``` であることを確認します。**

確認できたら、以下のコマンドを 1つずつ実行して、許可するポートを制限します。
```bash
$ ufw allow 22
$ ufw allow http
$ ufw allow https
$ ufw allow domain
```

そしてufwを有効化。
```bash
ufw enable
```

最後に ```ufw status``` を実行して、目的のポートが開放されていることを確認します。
```bash
$ ufw status
 Status: active

To Action From
 -- ------ ----
 22 ALLOW Anywhere
 53 ALLOW Anywhere
 22 (v6) ALLOW Anywhere (v6)
 53 (v6) ALLOW Anywhere (v6)
``` 

利用するVPSなどによっては、VPSのコントロールパネルなどで、  
別途、ポートの開放が必要です。

### Nginxでサーバの設定
ここでご紹介する方法では、Next.jsでジェネレートしたファイルを静的にNginxでサーブし、  
それとは別にStrapiでCMSをサーブします。

そのため、静的にサーブするドメインとCMSをサーブするドメインを別々に割り当てます。

#### Nginxで静的なサーブ
/etc/nginx/nginx.conf を設定して
```nginx
server {
    server_name  <サイト用のドメイン名>;

    location / {
        root   /var/www/<Next.jsのディレクトリ>/out;

        index  index.html index.htm;
    }

    error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

}
```

#### Strapi用の設定
/etc/nginx/conf.d/default.conf のhttpの設定で以下を設定
```nginx
http {
    ︙
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
```

/etc/nginx/sites-enabled/<Strapi用のドメイン名>
```nginx
server {

    listen 80;
    server_name <Strapi用のドメイン名>;

    # Proxy Config
    location / {
        proxy_pass http://127.0.0.1:1337;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_pass_request_headers on;
        add_header  X-Robots-Tag "noindex, nofollow, nosnippet, noarchive";
    }
}
```
あとは、```sudo nginx -t```でNginxの設定に問題がないことを確認し、```sudo systemctl start nginx```でNginxを起動すれば、  
Nginxの設定は完了です。

さらにUbuntu上でLet's EncryptによりSSLを設定する場合は、  
↓こちらの記事の方法がとても参考になります（Nginxの設定から更新まで自動！）。  
<a target="_blank" rel="noopener noreferrer" href="https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04-ja">Ubuntu 20.04でLet’s Encryptを使用してNginxを保護する方法  | DigitalOcean</a>


## Node.jsでNext.jsとStrapiの環境を準備
<a id="section2"></a>
Strapi公式のガイド: https://docs.strapi.io/dev-docs/integrations/next-js  
### Next.jsのインストール
```bash
$ npx create-next-app@latest
```
でNext.jsをインストールします。

### Strapiのインストール
ここでは、Next.jsをインストールした場所にstrapiをインストールしてみます。
StrapiをNext.jsと別の場所に置く場合などは、同じ場所にインストールしない方が良いでしょう。
```bash
$ cd <Next.jsをインストールしたディレクトリ>
$ yarn create strapi-app my-project --quickstart
```
でStrapiをインストールします。  
このとき、利用するDBをSQLite、MySQL、MariaDB、PostgreSQLから選択できます。  
SQLite以外を利用する場合は、別でMySQLなどインストール・きどうしておく必要があります。  
ここではMySQLを使った方法をご紹介します。  

### MySQLのインストール
参考にさせていただいたサイト: [Ubuntu 20.04にMySQLをインストールする方法  | DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-install-mysql-on-ubuntu-20-04-ja)
#### インストール
```bash
$ sudo apt update
$ sudo apt install mysql-server
```
#### 設定
##### パスワード
```bash
$ sudo mysql_secure_installation
```
ここでいくつか質問されるので、   
```Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:```では 2、   
```Re-enter new password:```では新たなパスワード、   
```Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : ```で Y   
として、パスワードを設定します。

##### ユーザ追加と権限の付与
```bash
$ mysql -u root -p
```
```mysql
CREATE USER 'ユーザ名'@'localhost' IDENTIFIED BY 'ユーザ名';
GRANT ALL PRIVILEGES ON * . * TO 'ユーザ名'@'localhost';
FLUSH PRIVILEGES;
```
##### Strapi用DBの作成
```mysql
exit
```
```bash
mysql -u ユーザ名 -p
```
```mysql
CREATE DATABASE strapi;
```
これでMySQLの準備は完了。  
Strapiのディレクトリに既にある.env、なければ新規に.envという名前のファイルを作り、以下のように記述  
.env  
```
︙
DATABASE_CLIENT=mysql2
DATABASE_HOST=127.0.0.1
DATABASE_PORT=3306
DATABASE_NAME=strapi
DATABASE_USERNAME=ユーザ名
DATABASE_PASSWORD=パスワード
DATABASE_SSL=false
```
続いて、./config/database.jsというファイルを開き、以下のように設定します。
```javascript
module.exports = ({ env }) => ({
  connection: {
    client: 'mysql',
    connection: {
      host: env('DATABASE_HOST', '127.0.0.1'),
      port: env.int('DATABASE_PORT', 3306),
      database: env('DATABASE_NAME', 'strapi'),
      user: env('DATABASE_USERNAME', 'strapi'),
      password: env('DATABASE_PASSWORD', 'strapi'),
      ssl: {
        rejectUnauthorized: env.bool('DATABASE_SSL_SELF', false), // For self-signed certificates
      },
    },
    debug: false,
  },
});
```

Strapiのディレクトリで以下コマンドを実行すると、Strapiが立ち上がり、表示されたURLにアクセスすると、ユーザ登録画面が表示されます。
```
yarn develop
```

## Next.jsとStrapiでデータを連携する
<a id="section3"></a>
### SSGでNext.jsからStrapiのAPIを呼び出す
※Strapiでrestaurantというコンテンツタイプを作った場合を例にしています（フィールドはtitleとslugを設定）。

SSGでNext.jsからAPIを呼び出す場合、pages/ のファイルで、```getStaticProps()```を使うことで、
ページをジェネレートする前にAPIを呼び出して、静的にHTMLを出力できます。
```typescript
import axios from 'axios'

function Page ({ posts, pagination, error } {
  return (
    <section>
      <h1>ページサンプル</h1>
      <ul>
        posts.map(post => (
          <li key={post.id}>{post?.attribute?.title}</li>
        ))
      </ul>
    </section>
  )
}

export async function getStaticProps () {
  try {
    const res = await axios.get('http://localhost:1337/api/restaurants');

    return {
      props: {
        posts: res?.data,
        pagination: {
          ...res?.meta?.pagination
        }
      }
    }
  } catch (error) {
    return { error }
  }
}

export default Page
```

#### ダイナミックルーティングでSSGする
pages/restaurants/[slug]/index.tsx のようにダイナミックルーティングでslugごとのページを生成したい場合、  
```getStaticPaths```を使います。  

```typescript
import axios from 'axios';

function Page ({ post } {
  return (
    <section>
      <h1>{post?.attribute?.title}</h1>
      ︙
    </section>
  )
}

export async function getStaticPaths () {
  let paths: (string | {
    params: ParsedUrlQuery;
    locale?: string | undefined;
  })[] = []
  const res = await axios.get(`http://localhost:1337/api/restaurants?pagination[pageSize]=10000&populate=slug`)
  if (res?.data?.length > 0) {
    paths = res?.data?.map(post => ({
      params: {
        slug: post?.attributes?.slug ?? null
      }
    }))
  }
  return { paths, fallback: false }
}

export async function getStaticProps ({ params }) {
  const res = await axios.get(`http://localhost:1337/api/restaurants?filters\[slug\][$eq]=${ params?.slug }`);

  return {
    props: {
      post: res?.data?.length > 0 ? res?.data[0] : undefined,
    }
  }
}

export default Page
```

# 対応してみた感想
WordPressに比べると、事前の準備も多く必要で、慣れるまでは大変かもしれません。  
SSGの場合、記事が多ければ多いほどビルドまでに時間がかかる問題もあります。  
ただ、基本的には1つの言語でバックエンドからフロントエンドまで調整することが可能で、  
SSGが故にクライアント側の表示は高速で、ビルドするとき以外はサーバの負担も軽くすみます。  
  
Strapiはコンテンツも自由に設定でき、実際に拡張性は高いと感じました。  
また、無料で試せるので、ヘッドレスCMSの練習としてもいいと思いました。

### 2023.8.28 追記
数百ページを超えるようなサイトでは、記事を更新するたびに全ページをbuildするSSGは向きません。  
その場合、Next.jsではISR(Incremental Static Regenerate)という仕組みが用意されていて、設定を工夫することで大量のページを含むサイトにも対応できるので、そちらの利用のご検討をおすすめします。

ubuntu-nginx-nextjs-strapi.jpg

Ubuntu✖️Nginx✖️Next.js(SSG)✖️StrapiでWEBサイトの環境を作る

【JavaScript】配列・オブジェクトの参照渡し&amp;コピーをクイズで理解する【React】

React Testing Library を使ってUIの結合テストをやってみる

【JavaScript】ブラウザのストレージCache APIを試してみる

【React】Dexie.jsでIndexedDBを使ってみました

【Javascript】var let const の使い分けとObjectの凍結・封印

<p>Node.jsでは有志たちによって非常に多くの便利な機能を提供してくれるモジュールを利用して様々なことができますが、<br>そういったサービスの中にはヘッドレスEコマースも存在していることを個人的に最近知ったので、そちらについて調べてみました。</p>



<p>今回は、以下のサイトで紹介されていたサービスの中から、Node.js ではじめられるものを2つピックアップして調べてみました。<br><a href="https://medevel.com/17-os-headless-ecommerce-solutions/" target="_blank" rel="noreferrer noopener">17 Best Open-source Headless eCommerce Solutions</a></p>



<p>ちなみにヘッドレスEコマースとは、ECのシステムにあたるバックエンドとECのサイトにあたるフロントを切り離し、バックエンド部分のみを提供し、APIを経由してフロントと連動するEC構築のサービスです。</p>



<p>ヘッドレスEコマースのメリットは、バックエンドがフロントエンドの出力を省略できるため、本来の役割に専念でき高いパフォーマンスを提供できることと、フロントエンドがバックエンドの制限を受けないため、幅広い方法でフロントエンドの開発を行えることです。</p>



<h2><a href="https://www.vendure.io/" target="_blank" rel="noreferrer noopener">vendure</a></h2>



<figure class="wp-block-image size-large"><a href="https://www.vendure.io/" target="_blank" rel="noopener"><img loading="lazy" width="1024" height="512" src="/uploads-archive/lc/2022/01/www.vendure.io_-1024x512.png" alt="" class="wp-image-9400" srcset="/uploads-archive/lc/2022/01/www.vendure.io_-1024x512.png 1024w, /uploads-archive/lc/2022/01/www.vendure.io_-300x150.png 300w, /uploads-archive/lc/2022/01/www.vendure.io_-768x384.png 768w, /uploads-archive/lc/2022/01/www.vendure.io_-600x300.png 600w, /uploads-archive/lc/2022/01/www.vendure.io_.png 1280w" sizes="(max-width: 1024px) 100vw, 1024px" /></a><figcaption><a rel="noreferrer noopener" href="https://www.vendure.io/" target="_blank">https://www.vendure.io/</a></figcaption></figure>



<p>インストールを以下のコマンド一発、5分で作れてしまうのが驚異的です。</p>





		<div id="crayon-64d1a7a2c67a1969614852" class="crayon-syntax crayon-theme-monokai crayon-font-monaco crayon-os-mac print-yes notranslate" data-settings=" minimize scroll-mouseover" style=" margin-top: 12px; margin-bottom: 12px; font-size: 12px !important; line-height: 15px !important;">
		
			<div class="crayon-toolbar" data-settings=" mouseover overlay hide delay" style="font-size: 12px !important;height: 18px !important; line-height: 18px !important;"><span class="crayon-title"></span>
			<div class="crayon-tools" style="font-size: 12px !important;height: 18px !important; line-height: 18px !important;"><div class="crayon-button crayon-nums-button" title="Toggle Line Numbers"><div class="crayon-button-icon"></div></div><div class="crayon-button crayon-plain-button" title="Toggle Plain Code"><div class="crayon-button-icon"></div></div><div class="crayon-button crayon-wrap-button" title="Toggle Line Wrap"><div class="crayon-button-icon"></div></div><div class="crayon-button crayon-expand-button" title="Expand Code"><div class="crayon-button-icon"></div></div><div class="crayon-button crayon-copy-button" title="Copy"><div class="crayon-button-icon"></div></div><div class="crayon-button crayon-popup-button" title="Open Code In New Window"><div class="crayon-button-icon"></div></div></div></div>
			<div class="crayon-info" style="min-height: 18px !important; line-height: 18px !important;"></div>
			<div class="crayon-plain-wrap"><textarea wrap="soft" class="crayon-plain print-no" data-settings="dblclick" readonly style="-moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4; font-size: 12px !important; line-height: 15px !important;">
npx @vendure/create my-shop</textarea></div>
			<div class="crayon-main" style="">
				<table class="crayon-table">
					<tr class="crayon-row">
				<td class="crayon-nums " data-settings="show">
					<div class="crayon-nums-content" style="font-size: 12px !important; line-height: 15px !important;"><div class="crayon-num" data-line="crayon-64d1a7a2c67a1969614852-1">1</div></div>
				</td>
						<td class="crayon-code"><div class="crayon-pre" style="font-size: 12px !important; line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4;"><div class="crayon-line" id="crayon-64d1a7a2c67a1969614852-1"><span class="crayon-i">npx</span><span class="crayon-h"> </span><span class="crayon-sy">@</span><span class="crayon-i">vendure</span>/<span class="crayon-e">create </span><span class="crayon-i">my</span>-<span class="crayon-i">shop</span></div></div></td>
					</tr>
				</table>
			</div>
		</div>





<p>GraphQLで通信を行います。</p>



<p>商品管理、注文管理、多言語・多通貨・複数の税率設定などのグローバル対応、画像のCloudストレージ、様々な決済プロバイダーやフルフィルメントへの接続方法の提供などに対応しています。</p>



<p>インストール自体は簡単ですが、実際に決済や配送などできる状態にするには、利用する開発者がそれなりに構築作業をする必要があり、誰でも簡単に始められるという感じではなさそうですが、<br>0からECを構築するよりは便利で、拡張性もあるため、自由にECを作りたい、でもすべて開発は…という層に人気が出るかもしれません。</p>



<p></p>



<h2><a href="https://www.medusajs.com/" target="_blank" rel="noreferrer noopener">Medusa</a></h2>



<figure class="wp-block-image size-large"><a href="https://www.medusajs.com/" target="_blank" rel="noopener"><img loading="lazy" width="1024" height="592" src="/uploads-archive/lc/2022/01/www.medusajs.com_-1024x592.png" alt="" class="wp-image-9402" srcset="/uploads-archive/lc/2022/01/www.medusajs.com_-1024x592.png 1024w, /uploads-archive/lc/2022/01/www.medusajs.com_-300x173.png 300w, /uploads-archive/lc/2022/01/www.medusajs.com_-768x444.png 768w, /uploads-archive/lc/2022/01/www.medusajs.com_-600x347.png 600w, /uploads-archive/lc/2022/01/www.medusajs.com_.png 1280w" sizes="(max-width: 1024px) 100vw, 1024px" /></a><figcaption><a href="https://www.medusajs.com/" target="_blank" rel="noreferrer noopener">https://www.medusajs.com/</a></figcaption></figure>



<p>REST APIで通信を行います。</p>



<p>商品管理、顧客管理、決済プロバイダーやフルフィルメントへの接続方法の提供などに対応しています。<br>vendure と異なり、フロントエンドのためのスターターの提供や、プラグインでstripe、paypalなどの支払い方法を追加できるので、<br>導入のハードルはこちらの方が低くなりそうです。</p>



<p></p>



<h2>調べてみた感想</h2>



<p>いずれもインストールは簡単ですが、実際に動くECを作るためにはかなり専門的な開発の知識が必須と言えそうです。<br>専門知識がなくても越境ECを始めたい方には、様々な機能がはじめから内包されているLaunchCartをおすすめしたいと思います。</p>

Node.jsがベースのオープンソースのヘッドレスEコマースについて調べてみました

BEM×SASSってもう古いの？？モダンCSSを試してみる(CSS Modules編)

BEM×SASSってもう古いの？？モダンCSSを試してみる(styled-components編)

JavaScriptのモダンなオブジェクトの構文・演算子


<p>WEBデザインの問題で改善が必要になったとき、いろいろな意見をどう整理して形にしていったらよいかで悩んでいたときに、以下の本に出逢いました。</p>



<figure class="wp-block-embed is-type-rich is-provider-amazon wp-block-embed-amazon"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="デザインリサーチの教科書" type="text/html" width="500" height="550" frameborder="0" allowfullscreen style="max-width:100%" src="https://read.amazon.com.au/kp/card?preview=inline&#038;linkCode=kpd&#038;ref_=k4w_oembed_E0y9HMFHnIjaQJ&#038;asin=4802511779&#038;tag=kpembed-20"></iframe>
</div><figcaption>デザインリサーチの教科書</figcaption></figure>



<p>この本を探した目的は、デザインする際、どのように情報を収集・整理したらよいかを改めて勉強するためだったのですが、<br>この本に書かれていた内容は、デザイナーの職種を超えて、問題解決のアイディアを形にするものでした。</p>



<p>自分なりにこちらの内容をごく一部ですが整理してみました。</p>



<h2>デザインが対象とするプロダクトと範囲の広がり</h2>



<p>19世紀に生まれた最初のデザインの対象はグラフィックのみでした（第一次デザイン）。デザインの手法はこの第一次デザインがベースとなっています。そこから20世紀にモノのデザイン、つまりインダストリアルデザインに広がります（第二次デザイン）。1980年代からは行動や体験をデザインするインタラクションデザイン（第三次デザイン）、2000年代には更にそこに持続可能性を考慮したデザインであるサービスデザイン（第三次デザイン）、そして2010年代にはビジネス・組織・教育・政府を対象としたシステムデザイン（第四次デザイン）にまで広がっています。この広がりの背景には、プロダクトの意味がモノからサービスへと移行してきたことがあり、それに伴い、デザインが必要とされる範囲もいろがってきたと考えられます。</p>



<p>この変化の中で、デザインの視野も同時に変化してきました。作り手の都合からユーザーの都合へ、ユーザーの都合から社会の都合へ、社会の都合から環境の都合へ。デザインの視野が広がるにつれ、そこに必要とされる要素も増えてきますので、綿密なリサーチが必要となってきます。</p>



<p>デザインの範囲がこれだけ広がってくると、必要な専門知識も広くなってくるため、デザイナーだけでデザインすることにも限界があり、職種をまたいでデザインしていく必要性も出てきます。</p>



<h2>マーケティングリサーチの限界とデザインリサーチの可能性</h2>



<p>未来の不確実性により、「十分に明確な未来」「選択的な未来」「ある範囲内の未来」「予測できない未来」に分けられます。</p>



<p>プロダクトの黎明期においては、十分に明確な未来となり、何を開発すれば売れるかという競争原理が明確です（CPUのクロック数を上げる、デジカメの画素数を上げる）。</p>



<p>プロダクトが成熟してくると、競合が増え「選択的な未来」となります（ブルーレイとHD DVD）。</p>



<p>更に先の未来を予測する場合には、「ある範囲内の未来」となり、ある程度の範囲に落ち着くことはわかっているが、いつになるかはわからないケースが出てきます（AIの浸透）。</p>



<p>更に会社の将来など、「予測できない未来」があります。</p>



<p>マーケティングリサーチで用いられるロジカルシンキングは確実性の高いリサーチに強く、不確実性が高いリサーチに弱いという問題があり、現在の変化が多く不確実性の高い時代においては不利となります。現代においては情報の入手が容易で競合との差がつけられない反面、情報が非常に膨大でロジカルな手法では把握しきれないという問題があるためです。</p>



<p>一方のインスピレーションを主軸とするデザインリサーチは不確実性が高いほど威力を発揮するため、今の時代において必要性が高まっています。競合がいない状況では一人ひとりにフォーカスするよりも、人々を大きく括ってプロダクトを作るほうが理にかなっていますが、競合が登場すると、一人ひとりがどのように生活しているかを知り、ニーズや要望を深く理解する必要があります。デザインリサーチではプロダクトに関わる一人ひとりにフォーカスし、そこからインスピレーションを得てアイディアにつなげていく手法を取ります。また、類推というデザインでよく行われる手法により、直接関係のないユーザーから新たなニーズを引き出すことも可能です。</p>



<p>同じく不確実性に対応するための開発手法であるアジャイルに自然に組み込むことができるのも、デザインリサーチ導入のメリットです。</p>



<h2>デザインリサーチの軸となるデザインプロセス</h2>



<figure class="wp-block-image size-full"><img loading="lazy" width="960" height="647" src="/uploads-archive/lc/2021/09/design-process-1.jpg" alt="" class="wp-image-8272" srcset="/uploads-archive/lc/2021/09/design-process-1.jpg 960w, /uploads-archive/lc/2021/09/design-process-1-300x202.jpg 300w, /uploads-archive/lc/2021/09/design-process-1-768x518.jpg 768w, /uploads-archive/lc/2021/09/design-process-1-600x404.jpg 600w" sizes="(max-width: 960px) 100vw, 960px" /><figcaption>「デザインリサーチの教科書」内のBritish Design Council「<a rel="noreferrer noopener" href="https://www.designcouncil.org.uk/resources/report/11-lessons-managing-design-global-brands" target="_blank">Eleven lessons: managing design in eleven global grands | The design process</a>」の改定をさらに改定</figcaption></figure>



<p>デザインリサーチの軸となるデザインプロセスでは、Descover（課題を洗い出す）→ Define（課題を絞り込む）→ Develop（課題を洗い出す）→ Deliver（解決策を絞り込む）という発散・収束を繰り返す4段階を通過します。</p>



<p>実際にはDevelopからDiscoverに戻る、解決から新たな課題を見出し課題に戻るというループを経ます。</p>


デザインリサーチとは１


<p><a rel="noreferrer noopener" href="https://qiita.com/ikea_shark_jk/items/deba88cbb8e5756fc929" target="_blank">HTML LSとHTML5の違いについてまとめ</a><br>今朝↑こちらの記事を読んで初めて知りましたが、2019年6月にHTMLの標準仕様がW3Cが策定しているものから、WHATWGが策定しているLiving Statndard(リビングスタンダード; 以降 HTML LS)に合意がなされ、以降はHTML LSがHTML5の標準仕様に替わっていました（合意の記事：<a rel="noreferrer noopener" href="https://www.itmedia.co.jp/news/articles/1906/10/news038.html" target="_blank">HTML標準仕様の策定についてW3CとWHATWGが合意 今後はWHATWGのリビングスタンダードが唯一のHTML標準仕様に</a> 2019.06.10）。</p>



<p><a rel="noreferrer noopener" href="https://qiita.com/ikea_shark_jk/items/deba88cbb8e5756fc929" target="_blank">参考記事</a>ではHTML LSとHTML5が別物のような書き方がされていましたが、正式にはHTML5の標準仕様がHTML LSになるということのようです（JavaScriptの標準仕様がECMAScriptである関係性に近いでしょうか）。</p>



<blockquote class="wp-block-quote"><p>Is this HTML5?<br>In short: Yes.<br>In more length: the term &#8220;HTML5&#8221; is widely used as a buzzword to refer to modern web technologies, many of which (though by no means all) are developed at the WHATWG. This document is one such; others are available from the WHATWG Standards overview.</p><cite><a rel="noreferrer noopener" href="https://html.spec.whatwg.org/multipage/introduction.html#abstract" target="_blank">Living Standard — Last Updated 1 July 2021</a> <a rel="noreferrer noopener" href="https://html.spec.whatwg.org/multipage/introduction.html#abstract" target="_blank">https://html.spec.whatwg.org/multipage/introduction.html#abstract</a></cite></blockquote>



<p>10年ほど前、まだスクールに通っていた頃、2つの団体がHTML5の標準規格を巡って対立しているということを何となく教えていただいたのを覚えていますが、それが続いていて、当時圧倒的だったW3Cからもう１つのWHATWGに替わっていたとは驚きです。</p>



<p>WHATWGはApple、Mozilla、Opera、そしてて2017年からはMicrosoftも加わって策定されているそうです（参考: <a rel="noreferrer noopener" href="https://ja.wikipedia.org/wiki/Web_Hypertext_Application_Technology_Working_Group" target="_blank">Web Hypertext Application Technology Working Group &#8211; Wikipedia</a>）。これだけ中心的な開発者が推進していれば、W3Cと代替わりしたのも今となっては納得です。と思いましたが、W3CもMozillaとOperaが共同で作成してました。</p>



<p>W3Cが完成されたHTML5の公開を目指しているのに対し、WHATWGはHTMLの生活水準(Living Standard)のために継続的に仕様をアップデートしていくことを基本としていて、技術の進歩を優先しているWHATWGの方針が、新たな技術が次々に求められる今のWEB事情にマッチしたことがWHATWGに標準が移った理由かもしれません。</p>



<p>私がよくHTML、CSS、JavaScriptの仕様を確認するときに利用させていただいている<a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/" target="_blank">MDN Web Docs</a>で仕様確認している場合は、<br>W3Cに限定せず、「信頼できる標準化団体 (W3C、WHATWG、Khronos、IETFなど) の下で公開された仕様書で指定されており、妥当なレベルの安定性に達している」ことと「他のブラウザー開発者が興味を引く兆しを見せており、少なくとも1つのブラウザーで一貫して実装されている場合 」を前提に新しいウェブ標準技術を適切に文書化することを前提としており(参考: <a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/MDN/Guidelines/Conventions_definitions" target="_blank">MDN の慣習と定義 &#8211; MDN プロジェクト | MDN</a>)、W3CとWHATWGの標準仕様がマージされているような状態だと推察されるので、<br>W3CからWHATWGに標準仕様が換わっていることを意識する必要はそれほどないと思いますが、<br><a rel="noreferrer noopener" href="https://www.w3.org/" target="_blank">W3Cのドキュメント</a>で仕様確認されていた場合は注意が必要です。</p>



<p>ルビ（&lt;rb&gt;、&lt;rtc&gt;）や一部属性など、W3Cでは標準仕様だったものが、WHATWGのHTML LSでは策定されていないものもあるようです。<br><a rel="noreferrer noopener" href="https://qiita.com/ikea_shark_jk/items/deba88cbb8e5756fc929" target="_blank">最初にご紹介した記事</a>にW3CのHTML5標準仕様と、WHATWGのHTML LSの違いについて紹介されています。</p>



<h2>参考にさせていただいたサイト</h2>



<ul><li><a rel="noreferrer noopener" href="https://qiita.com/ikea_shark_jk/items/deba88cbb8e5756fc929" target="_blank">HTML LSとHTML5の違いについてまとめ</a></li><li><a rel="noreferrer noopener" href="https://html.spec.whatwg.org/multipage/" target="_blank">Living Standard</a></li><li><a rel="noreferrer noopener" href="https://ja.wikipedia.org/wiki/Web_Hypertext_Application_Technology_Working_Group" target="_blank">Web Hypertext Application Technology Working Group &#8211; Wikipedia</a></li><li><a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/MDN/Guidelines/Conventions_definitions" target="_blank">MDN の慣習と定義 &#8211; MDN プロジェクト | MDN</a></li></ul>




HTML5がW3CからWHATWGが策定するLiving Standardに標準仕様が替わって2年たってた

最近APIで使われるGraphQLについて調べてみました


<p>文字の見やすさや美しさのためにカーニング（文字間隔）はTypographyにおいてとても重要です。<br>かつてWEB上では文字間隔で制御できるのはletter-spacing（等間隔で文字間隔を指定する）に限られ、半ば諦められていた項目でしたが、<br>フラットデザインが浸透し、Typographyの重要性が強くなったことや、text-align: justify;、font-feature-settings: &#8220;palt&#8221;; など文字間隔に関わるCSSの機能が充実してきたことなどで、WEBにおいてもカーニングが重要度を増してきているように感じます。<br>WEBのUIデザインツールとして人気を増しているFigmaでも１文字ごとのカーニングができるようになるなど、ツールの進化にもその重要性が見えてきます。</p>



<p>グラフィックデザインツールの大御所であるPhotoshopやIllustratorでは、カーニングに関する機能が充実しており、自動のオプションでかなり制度の高いカーニングが可能です。<br>ただ、自動オプションであるオプティカルやメトリクスって何だろうと思いながらも何となく使っていたのが正直なところです。</p>



<p>また、CSSで最近使われることの多くなってきた font-feature-settings: &#8220;palt&#8221;; というのも、何となく文字間隔がいい感じになるおまじないのような感覚で使ってきました。</p>



<p>ただ、何となく利用していると、使い方にむらが出たり、間違った使い方をしてしまう恐れもあります。<br>そこで今回、このあたりの機能について調べてみることにしました。</p>



<h2>PhotoshopやIllustratorのカーニングオプションについて</h2>



<h3>メトリクスカーニング</h3>



<p>Adobeの公式マニュアルを参照すると、</p>



<blockquote class="wp-block-quote"><p>メトリクスカーニングまたはオプティカルカーニングを使用すると、自動的に文字をカーニングすることができます。メトリクスカーニング（自動カーニングとも呼ばれます）では、ほとんどのフォントに含まれるペアカーニング情報が使用されます。ペアカーニングには、特定の文字の組み合わせに対する間隔情報が定義されています。この文字の組み合わせには、LA、P、To、Tr、Ta、Tu、Te、Ty、Wa、WA、We、Wo、Ya、Yo などがあります。メトリクスカーニングを使用するように初期設定されているので、テキストの入力または読み込み時に、特定の文字の組み合わせに対して自動的にカーニングが行われます。</p><cite>Adobe Photoshop での行と文字の間隔: <a rel="noreferrer noopener" href="https://helpx.adobe.com/jp/photoshop/using/line-character-spacing.html" target="_blank">https://helpx.adobe.com/jp/photoshop/using/line-character-spacing.html</a></cite></blockquote>



<p>とのこと。<br>欧文フォント自体に設定されているカーニングの情報を使ってカーニングを調整する方法のようですね。フォントを作った方が設定した情報をもとにカーニングを行うので、利用可能であれば、高い精度のカーニングができそうです。<br>欧文フォントとありますが、OpenTypeのフォントでは和文フォントでもペアカーニングが設定できるようなので、和文フォントでもフォントによっては利用できそうです。</p>



<h3>オプティカルカーニング</h3>



<blockquote class="wp-block-quote"><p>欧文フォントの中には、固有のペアカーニング情報を持っているフォントもありますが、最小限のカーニングしか定義されていないか、まったくカーニングが定義されていないフォントを使用する場合や、1 行内に異なるフォントやサイズを使用している場合は、オプティカルカーニングオプションを使用してカーニングを調整します。オプティカルカーニングでは、文字の形状に基づいて、隣接する文字の間隔が調整されます。</p><cite>Adobe Photoshop での行と文字の間隔: <a rel="noreferrer noopener" href="https://helpx.adobe.com/jp/photoshop/using/line-character-spacing.html" target="_blank">https://helpx.adobe.com/jp/photoshop/using/line-character-spacing.html</a></cite></blockquote>



<p>上記の通り、メトリクスカーニングはフォント自体に情報が設定されている場合にのみ利用でき、しかも設定されている文字の種類も限られている場合もあるため、フォントの情報に依存せずに設定するためにはオプティカルカーニングを利用する必要があるようです。<br>文字の種類の多い和文フォントではペアカーニングが設定されていない組み合わせも多そうですので、こちらを使うほうがいいかもしれません。</p>



<h3>プロポーショナルメトリクス</h3>



<p><a rel="noreferrer noopener" href="https://note.com/kyonskmt/n/n844b20b7f58b" target="_blank">こちらの記事（少しの工夫でグッと良くなる！タイポグラフィTIPS｜kyon｜note）</a>で紹介されているのを見て初めて知りましたが、OpenTypeで選択できるカーニングの機能で、日本語特有の文字幅や仮想ボディを考慮した自動も自爪で、日本語のデザインではぜひ使いたいカーニング方法です。</p>



<h2>font-feature-settings: &#8220;palt&#8221; とは？</h2>



<p>フォントデータとして使われることの多いOpenTypeのフォントですが、このOpenTypeには文字の形以外にもたくさんの情報が内蔵されています。<br>その中でも拡張タイポグラフィの機能を有効化して利用できるのが、font-feature-settingsです（参考: <a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/Web/CSS/font-feature-settings" target="_blank">font-feature-settings &#8211; CSS: カスケーディングスタイルシート | MDN</a>）。<br>OpenTypeの設定なので、基本的にはOpenTypeを利用したときでなければ利用できません。（※ OpenTypeやTrueTypeを圧縮することで生成されるWEBフォント用のフォントデータであるWOFFやWOFF2もフォントによってはFireFoxでは利用できるようです（参考: <a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/Web/Guide/WOFF" target="_blank">WOFF (Web Open Font Format) &#8211; 開発者ガイド | MDN</a>）。</p>



<p>&#8220;palt&#8221;は別名を Proportional Alternate Widths と呼び、それぞれの文字の幅に合わせてカーニングを調整する機能で、和文フォントで威力を発揮します（参考: <a rel="noreferrer noopener" href="https://docs.microsoft.com/en-us/typography/opentype/spec/features_pt#tag-palt" target="_blank">Registered features, p-t (OpenType 1.8.4) &#8211; Typography | Microsoft Docs</a>）。</p>



<p>文字詰め方法としては、PhotoshopやIllustratorのOpenType用の設定で利用できるプロポーショナルメトリクスと近い仕組みのようです。<br>日本語の場合、文字の種類や大きさが複雑なので、利用できるのであれば利用したい機能です。</p>



<h2>参考にさせていただいたサイト</h2>



<ul><li><a rel="noreferrer noopener" href="https://helpx.adobe.com/jp/photoshop/using/line-character-spacing.html" target="_blank">Adobe Photoshop での行と文字の間隔</a></li><li><a rel="noreferrer noopener" href="https://note.com/kyonskmt/n/n844b20b7f58b" target="_blank">少しの工夫でグッと良くなる！タイポグラフィTIPS｜kyon｜note</a></li><li><a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/Web/CSS/font-feature-settings" target="_blank">font-feature-settings &#8211; CSS: カスケーディングスタイルシート | MDN</a></li><li><a rel="noreferrer noopener" href="https://developer.mozilla.org/ja/docs/Web/Guide/WOFF" target="_blank">WOFF (Web Open Font Format) &#8211; 開発者ガイド | MDN</a></li><li><a rel="noreferrer noopener" href="https://docs.microsoft.com/en-us/typography/opentype/spec/features_pt#tag-palt" target="_blank">Registered features, p-t (OpenType 1.8.4) &#8211; Typography | Microsoft Docs</a></li><li><a href="https://www.morisawa.co.jp/culture/dictionary/1938" target="_blank" rel="noreferrer noopener">プロポーショナルメトリクス | フォント用語集 | 文字の手帖 | 株式会社モリサワ</a></li></ul>




Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - Author: ninomiya

2024/03/01

2023/10/05

2023/07/21

2023/02/03

2022/09/21

2022/08/26

2022/06/02

2022/03/25

2022/01/22

2021/12/10

2021/11/12

2021/10/12

2021/09/04

2021/07/02

2021/06/05

2021/05/14

2021/03/03

2021/02/06