large_eycatch-gemini-vs-cloud.png

medium_eycatch-gemini-vs-cloud.png

small_eycatch-gemini-vs-cloud.png

thumbnail_eycatch-gemini-vs-cloud.png

eycatch-gemini-vs-cloud.png

画像処理系AIの Gemini 2.5 Flash Image と Cloud Vision API を比べてみる（Next.jsの実装例付き）

## はじめに
ChatGPTなどのAPIを使うことで、これまで難しかった書類から必要な情報をピックアップする処理や、多言語への変換などがとても容易に行えるようになりました。
しかしながら、その処理はある程度の曖昧さを含まざるを得ないため、1回だけで最適な答えを出すこと難しいケースは多々あります。
そこで今回は、再帰的にChatGPTのAPIへ指示を出すことで、答えを洗練させられるかどうか、検証してみました。

## OpenAIチャットAPIでアイディアを再帰的に洗練させる

OpenAIのチャットAPIとTypeScriptを使い、アイディアを段階的に洗練させるプログラムを紹介します。  

### 作ってみたプログラム

```typescript
import dotenv from "dotenv";
import OpenAI from "openai";
import { zodResponseFormat } from "openai/helpers/zod";
import { z } from "zod";

dotenv.config({ path: `${__dirname}/.env` });

// APIの返答の形式を安定化させるため、Zodを使ってフォーマット指定を行います
const responseFormat = z.object({
  idea: z.string()
});

const main = async () => {
  // OpenAIの初期設定
  const client = new OpenAI({
    organization: process.env.CHAT_GPT_ORGANIZATION_ID,
    project: process.env.CHAT_GPT_PROJECT_ID,
    apiKey: process.env.CHAT_GPT_API_KEY
  });

  const MAX_COUNT = 5; // 再帰処理で呼び出す回数制限

  const getIdeas = async (
    question: string,
    ideas: string[],
    count: number = 1
  ) => {
    // 最初の指示
    let content = `## 指示
次に挙げる議題について、アイディアを出してください
「${question}」

## 制限事項
- 200文字程度で出してください`;

    // 再帰的に呼び出された時の指示
    if (count > 1) {
      content = `## 指示
次に挙げるアイディアを類推を使って洗練させてください
課題: ${question}
アイディア：「${ideas[ideas.length - 1]}」

## 制限事項
- 200文字程度で出してください`;
    }

    // チャットAPIの実行
    const chatCompletion = await client.chat.completions.create({
      model: "gpt-4o-mini",
      response_format: zodResponseFormat(responseFormat, "idea"),
      messages: [
        {
          role: "user",
          content
        }
      ]
    });

    // APIのレスポンスをパースして、情報を取得
    const responseMessage =
      JSON.parse(chatCompletion?.choices?.[0]?.message?.content ?? "{}")
        ?.idea ?? "";

    // 過去データに追加
    ideas.push(responseMessage);

    // 再帰的に呼び出す
    if (count < MAX_COUNT) {
      return getIdeas(question, ideas, count + 1);
    }

    return {
      question,
      ideas
    };
  };

  // 関数の実行
  const result = await getIdeas(
    "アジア向け越境ECを国内メーカーの販売担当者へ広告する場合の効果的なバナーデザイン",
    []
  );

  console.log(result);
};

main()
  .then(() => {
    console.log("Done");
  })
  .catch((error) => {
    console.error("Error:", error);
  });
```

#### プログラムの解説

- `.env`ファイルに定義されたAPIキーなどの環境変数を`dotenv`で読み込みます。
- Zodを使い、APIレスポンスの形式（idea: string）を指定することで、レスポンスの型を保証し、安定性を高めます。
- `getIdeas`関数は、指定回数（MAX_COUNT）まで再帰的にChatGPT APIへリクエストを送り、毎回新しいアイディアを生成・洗練します。
- 1回目は議題からアイディアを生成し、2回目以降は直前のアイディアをさらに洗練するよう指示します。
- すべてのアイディアは配列に蓄積され、最終的にまとめて出力されます。

### 実行結果例

#### 1回目
```md
1. クリーンでモダンなデザインを使用し、アジア市場を象徴する色彩（赤、金など）を取り入れる。
2. 商品写真を大きく配置し、目立たせることで視覚的インパクトを強調。
3. アジア顧客のニーズを反映したメッセージ（例：トレンド性や伝統的価値）を強調。
4. 言語はターゲット地域に応じたローカリゼーションを施し、親しみやすさを演出。
5. "越境ECで新市場開拓！"などのキャッチコピーで興味を引く。
```

#### 3回目
```md
アジア向け越境ECのバナーデザインには、
1. アジア特有の色（赤、金）を取り入れたクリーンでモダンなデザインが効果的。
2. 大きな商品写真でインパクトを与え、
3. トレンドと伝統を融合させたメッセージで興味を引く。
4. 各地域の言語で親しみやすさを演出し、
5. "新市場開拓のチャンス！"などの魅力的なキャッチコピーを加えることで、販売担当者の関心を高める。
```

#### 5回目
```md
「アジア向け越境ECのバナーデザインでは、
1. アジアの文化に根ざした明るい色合い（特に赤や金）を使用し、パッと目を引くデザインに。
2. 商品の魅力を伝えるために、大きな商品画像を配する。
3. トレンドと伝統を融合したキャッチコピーで感情に訴えかけ、
4. 地域ごとの言語で表記して親しみを感じさせる。
5. 更に、「新市場開拓は今がチャンス！」というポジティブなフレーズで顧客の関心を引く。
```

### 感想
結果を見てみると、アイディアそのものが洗練されているというより、文章として洗練されていっているという感じでした。
「洗練させる」ということが、人間にとっても解釈が難しいように、そもそも曖昧な指示なのが原因かもしれませんね。
また、ただ繰り返せばいいというわけではなさそうです。
ただし、情報を絞り込んでいくなど、プロンプトや利用目的を工夫すれば、この方法も有効に活用できる可能性があります。

### 注意
- 実案件でAPIを再帰的に利用する場合、API利用コストの増大や、レスポンスの質が頭打ちになる可能性についても、さらなる検証が必要です。

### 参考サイト
- <a href="https://platform.openai.com/docs/overview" target="_blank" rel="noopener noreferrer">Overview - OpenAI API</a>

large_eycatch.png

medium_eycatch.png

small_eycatch.png

thumbnail_eycatch.png

eycatch.png

OpenAIのチャットAPIを再帰的に呼び出す方法を検証してみた

## はじめに
UXデザインを改善しようとする際、どこから手をつければ良いか迷うことがあります。UXデザインを向上させるためには、アフォーダンス(Affordances)、シグニファイア(Signifiers)、フィードバック(Feedback)の3つの要素に分けて改善方法を検討すると、わかりやすくなります。これら3つの要素に分けて考えることで、UX改善に効果的にアプローチできることを学びましたので、それぞれの段階についてまとめてみました。

### アフォーダンス(Affordances)とは
デザイン用語としてのアフォーダンスとは、人と物との関係のことです。Webデザインの例では、クリックやスクロール、スワイプなどの操作が挙げられます。
元々の心理学の用語では、動物と物の間に存在する行為の関係性を表す言葉で、行為の選択肢の一つという意味合いが強いですが、デザインの領域では、**要素に対する行為**（**操作**）という意味で使われることが多いようです。
アフォーダンスを適切にデザインすることで、ユーザーの利用可能性を広げるだけでなく、間違った操作を予防する効果も期待できます。

### シグニファイア(Signifires)とは
シグニファイアとは、人と物との関係をユーザーに伝達するもので、わかりやすく言い換えると、**行為(操作)へ誘導するためのヒント**のことです。Webデザインの例では、クリックすることで意図した画面へ移動できるようにナビゲーションを工夫することや、スワイプが可能であることをわかりやすくすることが挙げられます。
シグニファイアを適切にデザインすることで、ユーザーが目的を達成するまでストレスなく到達できます。

### フィードバック(Feedback)とは
フィードバックとは、操作やアクションの後に即時の手応えや反応のことです。Webデザインの例では、クリックしたときのボタンの色の変化や、コンテンツの読み込み中や処理中のプログレスバーの表示などが挙げられます。
フィードバックを適切にデザインすることで、ユーザーに正しい操作をしていることを確信させ、安心して操作することをサポートできます。

## アフォーダンスを改善する方法
アフォーダンスには明示的なものと暗黙的なものがあり、特にWebデザイン領域では暗黙的なアフォーダンスが多く使われる傾向があります。例えば、画像をクリックすると拡大して表示されたり、左にスライドさせると削除される、一覧の一番上でさらに下にスクロール操作をすると最新情報に更新されるといった操作は、明確にUIとして示されず、ユーザーの経験によって成り立っています。

暗黙的なアフォーダンスはユーザーの直感に頼るため、学習コストが低い一方で、新しいユーザーには理解しづらい場合があります。逆に、明示的なアフォーダンスは誰にでも理解しやすいですが、デザインが煩雑になる可能性があります。したがって、広く一般化されたアフォーダンスではない限り、積極的に隠さない明示的なアフォーダンスを選択することが最善と言えます。

アフォーダンスを改善するためには、以下の点に注意することが重要です。
- **意図せず隠すアフォーダンスを避ける**: ユーザーが直感的に理解できるように、明示的なアフォーダンスを優先する。
- **デザインシステムの活用**: 既存のデザインシステムを利用するだけでなく、オリジナルのデザインシステムを構築する場合も、一般的なUIコンポーネントやパターンを参考にする。これにより、一貫性のあるデザインを実現しやすくなります。
- **多様な視点からの参考**: [マテリアルデザイン](https://m3.material.io/)や[Appleのデザインシステム](https://developer.apple.com/jp/design/)に加え、[Bootstrap](https://getbootstrap.jp/)や[Ant Design](https://ant.design/)などの他のデザインフレームワークも参考にする。これらのフレームワークから得られるベストプラクティスを取り入れることで、オリジナルのデザインシステムを強化できます。
- **ユーザーテストの実施**: オリジナルのデザインシステムを構築する際には、ユーザーテストを実施してフィードバックを収集し、アフォーダンスの改善に役立てる。

これらの方法を取り入れることで、アフォーダンスの質を向上させ、ユーザーが直感的に操作を理解できます。

## シグニファイアを改善する方法
シグニファイアは、ユーザーに対して行為(操作)を誘導するためのヒントを提供します。例えば、ハンバーガーメニューのアイコンがナビゲーションを開くためのボタンを意味していたり、虫眼鏡のアイコンがキーワード検索を開始するためのボタンを意味しているなど、アイコン自体がシグニファイアの役割を果たしている場面をよく見かけます。

シグニファイアを改善するためには、以下の点に注意することが重要です：
- **複数の手段を組み合わせる**: 一つの記号に頼らず、テキスト、コントラスト、色、シンボル、テクスチャなどを適切に組み合わせることで、ユーザーに対するヒントを強化します。
- **文化的背景を考慮する**: アイコンやシンボルが異なる文化や世代に対してどのように解釈されるかを考慮し、普遍的に理解されるデザインを目指します。例えば、フロッピーディスクを知らない世代には保存の意味が伝わりにくい、郵便マークも各国でシンボルが異なることがあるなどを考慮する必要があります。
- **補足情報を提供する**: アイコンだけでなく、テキストやツールチップを併用して意味を明確にすることで、ユーザーが直感的に操作を理解できるようにします。
- **一貫性を保つ**: 同じ意味を持つシグニファイアを一貫して使用することで、ユーザーの混乱を防ぎます。

これらの方法を取り入れることで、シグニファイアの効果を最大化し、ユーザーが直感的に操作を理解できます。

## フィードバックを改善する方法
Webにおいてフィードバックは、色の変化、画面の遷移、プログレスバー、メッセージの表示などで表現されます。適切なフィードバックは、ユーザーが操作の結果を理解しやすくし、次のアクションを促す役割を果たします。

例えば、ボタンをクリックした後に何も変化がないと、ユーザーはクリックできなかったと判断して操作を中断してしまいます。また、入力フィールドで間違った入力をしても何も変化がなければ、ユーザーは次のアクションを起こしづらくなります。

フィードバックを改善するためには、以下の点に注意することが重要です。
- **即時性**: ユーザーのアクションに対して即時にフィードバックを提供する。例えば、ボタンをクリックした際に色が変わる、プログレスバーが表示されるなど。
- **視覚的な変化**: 色の変化やアニメーションを利用して、ユーザーに操作が成功したことを視覚的に伝える。CSSの`:active`や`:focus`擬似クラスを利用すると簡単に実装できます。
- **明確なメッセージ**: エラーメッセージや成功メッセージを表示して、ユーザーが次に何をすべきかを明確に伝える。
- **ユーザーストーリーに沿った設計**: ユーザーの行動パターンを理解し、それに合わせたフィードバックを設計する。例えば、フォームの入力エラーをリアルタイムで表示するなど。

これらの方法を取り入れることで、フィードバックの質を向上させ、ユーザーが安心して操作できます。

## まとめ
UXデザインを向上させるためには、アフォーダンス、シグニファイア、フィードバックの3つの要素を適切にデザインすることが重要です。

- アフォーダンスは、ユーザーが直感的に操作を理解できるようにするための要素です。明示的なアフォーダンスを優先し、意図せず隠すアフォーダンスを避けることが重要です。既存のデザインシステムを活用するだけでなく、オリジナルのデザインシステムを構築する際には、一般的なUIコンポーネントやパターンを参考にし、ユーザーテストを実施してフィードバックを収集することが効果的です。
- シグニファイアは、ユーザーに対して行為を誘導するためのヒントを提供します。複数の手段を組み合わせ、文化的背景を考慮し、補足情報を提供することで、ユーザーが直感的に操作を理解できるようにします。また、一貫性を保つことで、ユーザーの混乱を防ぎます。
- フィードバックは、ユーザーの操作に対する即時の反応を提供し、次のアクションを促す役割を果たします。即時性、視覚的な変化、明確なメッセージ、ユーザーストーリーに沿った設計を取り入れることで、フィードバックの質を向上させ、ユーザーが安心して操作できます。

これらの要素を総合的に改善することで、ユーザーエクスペリエンスを向上させ、ユーザーが直感的に操作を理解し、ストレスなく目的を達成できます。

UXを改善したいけど、どこから直していけば良いか迷った場合は、ぜひ参考にしてみてください。

## 参考にさせていただいたサイト

- [3 Key Elements for Great UX Design: Affordances, Signifiers, and Feedback](https://careerfoundry.com/en/blog/ux-design/affordances-signifiers-feedback/)


large_image1.webp

medium_image1.webp

small_image1.webp

thumbnail_image1.webp

image1.webp

UXに大事なアフォーダンス(Affordances)・シグニファイア(Signifires)・フィードバック(Feedback) とそれぞれの改善について

## はじめに

2023 年 10 月ごろに、[Recoil と Jotai に関する記事](https://sterfield.co.jp/blog/which-recoil-or-jotai/)を投稿しましたが、2023 年 3 月以降、Recoil の更新が進められていない状況で、React 19 以降では正常に動作しない見込みとなってきました[<a href="https://github.com/facebookexperimental/Recoil/issues/2318#issuecomment-2120383312" target="_blank">参考</a>]。  
そのため、これまで Recoil を使ってきた React のプロジェクトにおいて、別の状態管理ライブラリへの移行が必要となり、対応を進めています。  
その選択肢の一つとして、Redux への移行を行ったので、そのときの方法を Recoil と Redux のコードを比べながら、通常の状態と、API との通信を伴う非同期の状態の移行に分けて、ご紹介します。  
ここでご紹介する方法は、Redux は、Redux Toolkit と React Redux の利用を前提にしています。

## インストール

Recoil から Redux へ移行する場合、Redux Toolkit と React Redux を使うことで、Recoil のときと同じようなコードの書き方で、スムーズに移行できるので、そちらをインストールします。

```bash
npm i @reduxjs/toolkit react-redux
```

## ファイルの準備

以下はファイル構成の例です。

```
redux
├ hooks/ // React用のHooksを格納する
│ ├ normalExample.ts
│ ├ familyExample.ts
│ ┗ asyncExample.ts
├ slices/ // ReduxのSliceを格納する
│ ├ normalExampleSlice.ts
│ ├ familyExampleSlice.ts
│ ┗ asyncExampleSlice.ts
┗ store.ts  // Reduxのstore
```

## 通常の状態

### Recoil

```typescript
import {
  atom,
  useRecoilValue,
  useResetRecoilState,
  useSetRecoilState,
} from "recoil";

// Recoilのatomを設定
export const normalExampleState = atom<string>({
  key: "normalExample",
  default: "",
});

// get state
export const useNormalExampleValue = () => useRecoilValue(normalExampleState);

// set state
export const useSetNormalExampleState = (key) =>
  useSetRecoilState(loadingState);

// reset state
export const useResetNormalExampleState = () =>
  useResetRecoilState(normalExampleState);
```

上記のような状態を Recoil で設定していた場合、Redux Toolkit と React Redux を使って以下のように置き換えることができます。  
ご覧いただくとわかりますが、reducer による action の設定や Root の store.ts への設定のところが Recoil にはない記述ですが、それ以外は似たコードで構成できることがわかります。

### Redux

redux/slices/normalExampleSlice.ts

```typescript
import { createSlice, type PayloadAction } from "@reduxjs/toolkit";

const initialState = "";

// ReduxのSliceを設定
export const normalExampleSlice = createSlice({
  name: "normalExample",
  initialState,
  reducers: {
    // set
    setNormalExample: (state, action: PayloadAction<string>) => {
      state.normalExample = action.payload;
    },
    // reset
    resetNormalExample: (state) => {
      state.normalExample = "";
    },
  },
});

export const { setNormalExample, resetNormalExample } =
  normalExampleSlice.actions;

export default normalExampleSlice.reducer;
```

redux/store.ts

```typescript
import { configureStore } from "@reduxjs/toolkit";
import { TypedUseSelectorHook, useSelector } from "react-redux";
import normalExample from "./slices/normalExampleSlice";

// 用意したSliceをstoreに登録する
export const store = configureStore({
  reducer: {
    normalExample,
  },
});

export type AppStore = typeof store;

export type RootState = ReturnType<AppStore["getState"]>;

export type AppDispatch = AppStore["dispatch"];

// useSelectorでは型が引き継がれないので、TypeScriptでは型を引き継げるuseAppSelectorを用意する
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;
```

React 用の Hooks は、以下のように React Redux の useDispatch と useSelector（TypeScript の場合は store.ts で定義した useAppSelector）を利用して以下のように構成できます。

redux/hooks/normalExampleSlice.ts

```typescript
import { useDispatch } from "react-redux";
import { useCallback } from "react";
import {
  setNormalExample,
  resetNormalExample,
} from "@/redux/slices/normalExampleSlice";
import { useAppSelector, type RootState } from "../store";

// get state
export const useNormalExampleValue = () =>
  useAppSelector((state: RootState) => state.normalExample);

// set state
export const useSetNormalExampleState = () => {
  const dispatch = useDispatch();
  return (value: string) => {
    dispatch(setNormalExample(value));
  };
};

// reset state
export const useResetNormalExampleState = () => {
  const dispatch = useDispatch();
  return () => {
    dispatch(resetNormalExample(value));
  };
};
```

## AtomFamily からの移行

Recoil では、atomFamily という、同じ型の状態をキーごとに再利用するための便利な機能が用意されていますが、Redux Toolkit の Slice でも、以下のように構成することで、似た機能を実装できます。

### Recoil

```
import { atomFamily } from "recoil";

import {
  atom,
  useRecoilValue,
  useResetRecoilState,
  useSetRecoilState,
} from "recoil";

// RecoilのatomFamilyを設定

export const familyExampleState = atomFamily<string, string>({
  key: "familyExample",
  default: null
});

// get state
export const useNormalExampleValue = (key: string) => useRecoilValue(familyExampleState(key));

// set state
export const useSetNormalExampleState = (key: string) =>
  useSetRecoilState(familyExampleState(key));

// reset state
export const useResetNormalExampleState = (key: string) =>
  useResetRecoilState(familyExampleState(key));
```

### Redux

redux/slices/familyExampleSlice.ts

```typescript
import { createSlice, type PayloadAction } from "@reduxjs/toolkit";

export interface FamilyExampleState {
  [key: string]: string | null;
}

const initialState: FamilyExampleState = {
  default: null,
};

const familyExampleSlice = createSlice({
  name: "familyExample",
  initialState,
  reducers: {
    // set
    setFamilyExample(
      state,
      action: PayloadAction<{ key: string; value: string }>
    ) {
      state[action.payload.key] = action.payload.value;
    },
    // reset
    resetFamilyExample(state, action: PayloadAction<string>) {
      state[action.payload] = null;
    },
  },
});

export const { setFamilyExample, resetFamilyExample } =
  familyExampleSlice.actions;

export default familyExampleSlice.reducer;
```

redux/hooks/familyExampleSlice.ts

```typescript
import { useDispatch, shallowEqual } from "react-redux";
import { type RootState, useAppSelector } from "../store";
import {
  setFamilyExample,
  resetFamilyExample,
} from "../slices/familyExampleSlice";

export const useFamilyExampleValue = (key: string) =>
  useAppSelector((state: RootState) => state.familyExample[key], shallowEqual);

export const useSetFamilyExampleState = (key: string) => {
  const dispatch = useDispatch();
  return (value: string) => {
    dispatch(setFamilyExample({ key, value }));
  };
};

export const useResetFamilyExampleState = (key: string) => {
  const dispatch = useDispatch();
  return () => {
    dispatch(resetFamilyExample(key));
  };
};
```

## API 通信を伴う非同期の状態

API からのデータ取得など、非同期を伴う場合、Redux への移行には少しなれがひつようかもしれません。
以下のような Recoil では selector で API からのデータ取得を伴う状態を構成していた場合を移行する場合の例です。

### Recoil

```typescript
import {
  atom,
  selector,
  useSetRecoilState,
  useRecoilValue,
  useRecoilRefresher_UNSTABLE,
} from "recoil";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery } from "@/api/query/exampleQuery";

export const asyncExampleState = selector({
  key: "asyncExample",
  get: async () => {
    const { data, errors } = await apolloClient.query({
      query: exampleQuery,
      fetchPolicy: "no-cache",
    });
    if (errors) {
      throw errors;
    }
    return data.example;
  },
});

// get state
export const useAsyncExampleValue = () => useRecoilValue(asyncExampleState);

// reset state
export const useResetAsyncExampleState = () =>
  useRecoilRefresher_UNSTABLE(asyncExampleState);
```

### Redux

Redux Toolkit で非同期を伴う Slice を作成する場合、createAsyncThunk と createSlice の extraReducers で構成します。

redux/slices/asyncExampleSlice.ts

```typescript
import { createSlice, createAsyncThunk, PayloadAction } from "@reduxjs/toolkit";
import type { ApolloError } from "@apollo/client";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery, type Example } from "@/api/query/exampleQuery";
import type { RootState } from "../store";

// API用の状態の型を定義
const initialState: {
  data: Example[];
  status: "idle" | "loading" | "succeeded" | "failed";
  error: ApolloError;
} = {
  data: [],
  status: "idle",
  error: null,
};

// 非同期用のreducerを設定
export const fetchAsyncExample = createAsyncThunk<
  Example[],
  void,
  { state: RootState }
>("asyncExample/fetchAsyncExample", async (_, { rejectWithValue }) => {
  const { data, errors } = await apolloClient.query({
    query: exampleQuery,
    fetchPolicy: "no-cache",
  });

  if (error) {
    return rejectWithValue(error);
  }

  return data.example;
});

// SliceにextraReducersを使って非同期用のreducerを紐づける
export const asyncExampleSlice = createSlice({
  name: "asyncExample",
  initialState,
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchAsyncExample.pending, (state) => {
        state.status = "loading";
      })
      .addCase(fetchAsyncExample.fulfilled, (state, action) => {
        state.status = "succeeded";
        state.data = action.payload;
      })
      .addCase(fetchAsyncExample.rejected, (state, action) => {
        state.status = "failed";
        state.error = action.payload as any;
      });
  },
});

export default asyncExampleSlice.reducer;
```

redux/hooks/asyncExampleSlice.ts

```typescript
import { useDispatch, shallowEqual } from "react-redux";
import { type RootState, useAppSelector } from "../store";
import { fetchAsyncExample } from "../slices/asyncExampleSlice";

// get state
export const useAsyncExampleValue = () => {
  const dispatch: AppDispatch = useDispatch();
  const { data, status } = useAppSelector(
    (state: RootState) => state.example,
    shallowEqual
  );

  // 状態が"idle"の時はfetchを実行する
  useEffect(() => {
    if (status === "idle") {
      dispatch(fetchAsyncExample());
    }
  }, [status, dispatch]);

  return data;
};

// reset state
export const useResetNormalExampleState = () => {
  const dispatch = useDispatch();
  return () => {
    dispatch(fetchAsyncExample());
  };
};
```

## 移行途中で Recoil と依存する状態を連携させる場合

移行途中で共存させなければならない場合、以下のように Recoil に依存する状態を Redux と連携できます。
ただし、Recoil 同士の状態と違い、Redux の状態の変化を Recoil は自動で検知してくれないので、Redux の状態を変更するときに、Recoil で Reset や Refresh を実行する必要があることの注意が必要です。

```typescript
import { selector } from "recoil";
import { store } from "@/redux/store";
import { apolloClient } from "@/api/apollo-client";
import { exampleQuery, type Example } from "@/api/query/exampleQuery";

export const exampleState = selector({
  key: "exampleState",
  get: async ({ get }) => {
    const keyword = store.getState().keyword;

    const { data, errors } = await apolloClient.query({
      query: exampleQuery,
      variables: {
        keyword,
      },
      fetchPolicy: "no-cache",
      errorPolicy: "all",
    });
    if (errors) {
      throw errors;
    }
    return data.example;
  },
  cachePolicy_UNSTABLE: {
    eviction: "most-recent",
  },
});
```

## まとめ

Recoil の atom や selector の書き方と Redux Toolkit の createSlice の書き方が似ていることもあり、意外とコードの移行の親和性が高いと感じました。  
ただ、非同期関係では Redux において createAsyncThunk を利用するなど、Recoil にはない独特の記述も必要で、慣れが必要な部分も実感しました。

## 参考リンク

- Recoil の更新状況: <a href="https://github.com/facebookexperimental/Recoil/issues/2318#issuecomment-2120383312" target="_blank">React 19 support · Issue #2318 · facebookexperimental/Recoil</a>
- Recoil の更新状況: <a href="https://recoiljs.org/blog" target="_blank">Blog | Recoil</a>
- Redux Toolkit の使い方 (はじめ方): <a href="https://redux-toolkit.js.org/tutorials/quick-start" target="_blank">Quick Start | Redux Toolkit</a>
- Redux Toolkit の使い方 (TypeScript): <a href="https://redux-toolkit.js.org/tutorials/typescript" target="_blank">TypeScript Quick Start | Redux Toolkit</a>
- Redux Toolkit の使い方 (非同期の状態): <a href="https://redux-toolkit.js.org/api/createAsyncThunk" target="_blank">createAsyncThunk | Redux Toolkit</a>

medium_20240719_recoil-to-redux.png

small_20240719_recoil-to-redux.png

thumbnail_20240719_recoil-to-redux.png

20240719_recoil-to-redux.png

Recoil から Redux へ移行するときにやったこと

## はじめに
フロントエンドにおいても、製品の品質を向上させ、維持していく上で、テストは必須と言えるほど重要になってきています(参考: <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)

small_nino-eye.jpg

thumbnail_nino-eye.jpg

nino-eye.jpg

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

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

**[2024.6.3 追記] Recoilから正式に発表されているわけではありませんが、2023年3月以降アップデートがなく、Recoilの開発は実質的に打ち切られてしまったようです。そのため、Recoilを選択することは避けた方がよさそうです…  
参考: <a href="https://github.com/facebookexperimental/Recoil/issues/2318" target="_blank">React 19 support · Issue #2318 · facebookexperimental/Recoil</a>**

**→ [2024.7.19 追記] [Reduxへ移行する方法の記事](https://sterfield.co.jp/blog/recoil-to-redux/)を投稿しました。**

## まず 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)

medium_20231006_1.png

small_20231006_1.png

thumbnail_20231006_1.png

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)という仕組みが用意されていて、設定を工夫することで大量のページを含むサイトにも対応できるので、そちらの利用のご検討をおすすめします。

medium_ubuntu-nginx-nextjs-strapi.jpg

small_ubuntu-nginx-nextjs-strapi.jpg

thumbnail_ubuntu-nginx-nextjs-strapi.jpg

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年たってた

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - Author: ninomiya

2025/10/02

2025/05/22

2024/12/06

2024/07/19

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