When I'm not coding, wathing youtube videos or playing game, you'll find me cooking, working out in the park or drinking somewhere.

## 登壇しました

結構時間は経ってしまったけど7月にエンジニア向けのイベントでLTの登壇した。
いくつかLT登壇は今まで何回かしていたが、会社名を出して代表として出たので初めてだったので軽く準備過程を書いてみることにした。

## 登壇テーマ

最初は会社で立ち上げようとしていた新規プロダクトの話をするつもりだった。イベントのテーマ自体もフロントエンドだったので新規プロダクトを立ち上げる上での何かをしゃべれば面白いかも、と思って準備していた。
しかし、イベントの日にはまだ新規プロダクトの __プレスリリースが出ていない__ ことからイベントではプロダクト名とあまり詳しい内容を述べてはいけなく、内容として面白くなかったのでテーマを変更。

それで結局決めたのは __フロントエンドとフィードバック・テスト__ についてUzabaseはどうやっているのかを書いてみることにした。当たり前に見えるかも知れないけど最も大事で結構助けられる部分でもあるので自分のためにもまとめてみることにした。

## フィードバックは大事

```
フィードバックサイクルをいかに早く、多く回すか
```

今回のLTで話したかったことはこの一言になる。サービスの開発でフィードバックサイクルを早く、多く回すかはサービスの質に大きく影響するのですごく重要なポイントの一つ。
その中で __多く回す__ と __早く回す__ はそれぞれ技術的なところとそれ以外の所で今回のプロダクトで気をつけたことを述べてみる。

### フィードバックを多く回す

トライアルのユーザーを集めて使ってもらうのもすごく良いプラクティスだが、既にあるサービスの追加機能とかでなく完全新規のプロダクトの場合はそれもできないかも知れない。 __まだログインしかできないけどフィードバックください__ とは中々言いにくいと思う。

そのため外部から集めるのは難しいので内部の資源を上手く活用していくことにした。
まだリリース前のサービスの一番のユーザーはやはり __開発しているエンジニアである__ のでエンジニアからも開発しながら結構なフィードバックを元に改善をしていた。
最初は定まってなかったデザインの基盤もデザイナーさんと多く議論をする中で作り上げていって、最終的には __デザインガイドライン__ を定義できた。コンポーネント設計ではAtomic Designも採用していたのでガイドラインを元にUIフレームワークのように作れたので今後もデザインの統一性は担保できると思っている。

また、Uzabaseではフィードバックは基本的に実際の動いている本番環境を元に行われる。まだ公開してないのでアクセス制限はかけていたが、 __実際のユーザーが使う環境と同じ__ にした上でフィードバックを集めるのでそれらを実現するための工夫はいくつかあるのでまた下で記述する。

### フィードバックを早く回す

フィードバックを早く回すための工夫は大きく２つ。

- CI/CD
- 常にMVPを意識する

__CI/CD__ はフィードバックを早く回すためだけでなく、多く回すためにも必要になる。上で __実際のユーザーが使う環境と同じ__ 環境でフィードバックを集めると書いてあるので開発が終わったユーザーストーリーを本番環境にリリースしないとフィードバックは集まらない。一つのユーザーストーリーであってもフィードバックを早く・多く集めるためにはできるだけ早く本番にリリースする必要がある。

しかし本番環境までリリースする手順が複雑だと __リリース回数は当然落ちる__ のでCI/CDの効率化は大事になる。そこで今回は __ArcoCD・Helmを使ったGitOps__ を採用した。
アプリケーション自体はk8sで動いていたのでHelmでマニフェストを作り、ArgoCDでそれをデプロイする流れになる。

![argocd gitops](//images.contentful.com/dtew01bna6pd/G12sOcnUzmmPQqujBhZEY/d9af2c3f5432915ec5a0f5a2aab8ff25/____________________________2021-07-31_16.41.01.png)

また、 __常にMVPを意識する__ もすごく重要である。リリースを早くするには各ユーザーストーリーのMVPを常に意識し、早く終わらせて早くリリースする必要がある。 __ストーリーのゴールが不明確であればすぐに相談する__ 、 __追加の開発が必要であれば別のユーザーストールを作成する__ 、 __対応のタイミングや優先順位を議論する__ などアジャイル的なスキルが求められる。こういった議論を繰り返すことで今のユーザーに
多くの価値がある機能を早めに出していくことができる。
もちろんこれはもの凄く難しい部分だが、アジャイルの基礎を心かけてトライアンドエラーを繰り返すと精度も上がってくると思う。

## テストをしっかり書こう

上記の __フィードバックを多く回す__ や __フィードバックを早く回す__　を実現するためにはCI/CDを整えることやアジャイル的に意識するなども大事だが、それらを支えるのはやはり __自動テストを書くこと__ だと考える。

自動テストがないとマニュアルテストで確認するしかないので早く・多くリリースすることに大きく影響する。どんなに早くて使いやすいCIツールがあってもテストにもの凄く時間が掛かっていたら意味はない。
また、フィードバックを集めていたら当然計画は変わる。計画していた機能がなくなったり、新しくできたりすることもあれば既に作った機能の仕様が変わることもあるだろう。自動テストがないとその __変化に対応しにくくなる__ 。アジャイルで開発をしていたら計画は同然変わるものだと認識をした方が良いと思っている。

エンジニアとして __ここの仕様が変わったのでもうその期日には間に合いません__ と返すのはUzabaseのバリューとは合わないので変わるであろう計画に柔軟に対応するためにもテストはすごく大事である。

### ほんで、どんなテストを書くべきか？

テストにはいくつか種類があるが、ここで主に話しているテストのことは __フロントのE2E__ のこと。
もちろんユニットテストは要らないという意味ではなく、E2Eも含めて書いた方が良いという思っている。

チームではE2Eを書く際には __Gauge + Chrome Driverを使った Seleniumのテスト__ で書いている。

```text
# マイページの項目の更新
* トップページにアクセスする
* メールアドレス"test@uzabase.com"パスワード"password"でログインする 
* マイページが表示されている

## メールアドレスを更新することができる - mailaddress * メールアドレスに"test@uzabase.com"が表示されている * メールアドレスに"update@uzabase.com"を入力する
* 更新ボタンを押下する
* メールアドレスに"update@uzabase.com"が表示されている * DBが更新されている
* 外部のAPIにリクエストが行われている
```

簡単に書くとこんな感じ。実際のユーザーが行う操作を書いていって、それを結果を評価する。
Documentにあるelementが描画されているのか、そのelementがどの状態なのが、どういう値を持っているのかなどの確認から、DBやElastic Searchにどういう値が保存されたのかや、外部のAPIにちゃんと通信しているのかなどまで検証できるのですごく便利。

### 自動テストの効果

自動テストは色々効果はあるが、結構書くのに時間がかかる。それに最初自動テストの基盤を作る際には更に時間がかかるでしょ。サービスの開発ではスピードはすごく大事に指標なので逆にテストに時間がかかり過ぎて開発が進まなくなるのは本末転倒である。

それでは自動テストを書くことで消費したコスト（時間）は __いつ回収できるのか？__

![test cost](//images.contentful.com/dtew01bna6pd/6lGAN2YHpjbznWHi0m886o/8a3cf5789f598a2ecfebb3ded6b87b7b/____________________________2021-07-07_14.56.03.png)

[質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition](https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=69)

以前Uzabaseでt_wadaさんの登壇があって、その資料を引用する。
自動テストを書くことで消費したコストはマニュアルテスト3回を回すと逆転する。３回はストーリーの状況では1日もかからない時も多々あるので確実にマニュアルテストより効率的だと言える。

## まとめ

なんか色々書いてはいたが、フロントエンドに限っての話ではないので少し滑った感じはしていた。
UI/UXなどの外部品質に関するものを改善するにはテストやCI/CDなどの内部品質を上げる必要がある、と言いたかったが、少し外れたかもなぁと思ったので次回もあればその時でこそ新規プロダクトの話がしたい。

[登壇資料 | 新規プロダクト立ち上げとフロントエンド設計](https://speakerdeck.com/dordieux/xin-gui-purodakutoli-tishang-getohurontoendoshe-ji)

【PLAID×SmartHR×Uzabase×OPEN8】 SaaSプロダクトのフロントエンド最前線に登壇したお話

そう言えば、登壇してたわ

この間ブログにダークモードを実装してみた。
Reactでは結構簡単にできたのでサンプルコードを含めてできるだけ解説する。

## ダークモードとは

> It means that, instead of the default dark text showing up against a light screen (known as ‘light mode’), a light colour text (white or grey) is presented against a dark or black screen.

普段使われる明るい背景に暗い文字ではなく、暗い背景に明るい文字を表示させること。
自分はウェブやアプリ関係なくダークモードで設定するのが好きだが、今更自分のブログにダークモードがなかったのでNext.jsで簡単に作ってみた。

[forbes | what is dark mode](https://www.forbes.com/uk/advisor/mobile-phones/what-is-dark-mode-and-should-you-be-using-it/)

## モードを設定する

ブログにモードの設定をしていればその設定に従い、設定がなければユーザーのブラウザの設定に従う。
ここは好みだが、どっちも __設定されてなければデフォルトでdarkにする__ 

```JSX
import React from "react";

export default function ThemeScript() {
  return (
    <script
      dangerouslySetInnerHTML={{
        __html: blockingSetInitialColorMode,
      }}></script>
  );
}

const blockingSetInitialColorMode = `(function() {
	${setInitialColorMode.toString()}
	setInitialColorMode();
})()
`;

function setInitialColorMode() {
  function getInitialColorMode() {
    const persistedColorPreference = window.localStorage.getItem("theme");
    const hasPersistedPreference = typeof persistedColorPreference === "string";

    if (hasPersistedPreference) {
      return persistedColorPreference;
    }

    const mql = window.matchMedia("(prefers-color-scheme: dark)");
    const hasMediaQueryPreference = typeof mql.matches === "boolean";

    if (hasMediaQueryPreference) {
      return mql.matches ? "dark" : "light";
    }

    return "dark";
  }

  const colorMode = getInitialColorMode();
  const root = document.documentElement;
  root.style.setProperty("--initial-color-mode", colorMode);

  if (colorMode === "dark") document.documentElement.setAttribute("data-theme", "dark");
}
```

アプリケーションのテーマの設定は __localStorageに保存しておく__ 。
localStorageに入れておくことで、再訪問時にも前回と同様なモードで見ることができる。

ユーザーのブラウザなどの設定を読みことのが __prefers-color-scheme__ 
モダーンブラウザではサポートされているので使うのに問題はないと思う。

### スクリプト配置

ドキュメント(_document)に このスクリプトを入れておく。
画面のRenderingの前に設定をするのでbodyの先頭に入れておく。

```JSX
export default class MyDocument extends Document {
  render() {
    return (
      <Html>
        <Head />
        <body>
          <ThemeScript />
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}
```

## モードを適応させる

設置したモードをアプリケーション側で使うには、 __Contextを使って、下のレイヤーで参照する__

一つ目の `useEffect` で、設定されたモードをモードとして使わせる。
二つ目の `useEffect` で、document側にモードを設定させることで実際の色を切り替えることができる。 これはこの後のモードごとに色を設定する部分で実際に使われる。

下位のレイヤーでこのコンテキストを使って色を切り替えるので、colorModeを変更する __toggleColorMode__ 関数も用意しておく。そうすることで他のComponentでは色の変更処理を意識することなく、関数を呼び出すだけで色がしてできる。

__prefers-color-scheme__ を使ってユーザーの設定を読み込んでるのでアプリ内で切り替えるのは無駄かもしてないが、ブラウザによっては設定できないようなのであっても良いと思う。

```JSX
import React, { createContext, useEffect, useState } from "react";

type ContextProps = {
  colorMode: string;
  toggleColorMode: () => void;
};

export const ThemeContext = createContext({} as ContextProps);

export const ThemeProvider = ({ children }) => {
  const [colorMode, setColorMode] = useState(undefined);

  useEffect(() => {
    const root = window.document.documentElement;
    const initialColorValue = root.style.getPropertyValue("--initial-color-mode");
    setColorMode(initialColorValue);
  }, []);

  useEffect(() => {
    if (colorMode !== undefined) {
      if (colorMode === "dark") {
        document.documentElement.setAttribute("data-theme", "dark");
      } else {
        document.documentElement.removeAttribute("data-theme");
      }
    }
  }, [colorMode]);

  const toggleColorMode = () => {
    const theme = colorMode === "dark" ? "light" : "dark";

    window.localStorage.setItem("theme", theme);
    setColorMode(theme);
  };

  return <ThemeContext.Provider value={{ colorMode, toggleColorMode }}>{children}</ThemeContext.Provider>;
};
```

### ThemeProviderを配置

Providerは _appの下に配置しておく。

```JSX
function App({ Component, pageProps }: AppProps) {
  return (
    <ThemeProvider>
      <Component {...pageProps} />
    </ThemeProvider>
  );
}
```

## モードごとに色を切り替える

これは使うCSSのライブラリーによって使い方は変わると思うが、自分はEmotionを使って説明する。
上記の手順でモードをアプリ側に適応させることはできてるので、色を指定することが簡単にできる。

```JSX
export default function App({ Component, pageProps }: AppProps) {
  return (
    <>
      <Head>
        <Global styles={color} />
      </Head>
      <ThemeProvider>
        <Component {...pageProps} />
      </ThemeProvider>
    </>
  );
}

const color = css`
  :root {
    --color-text: black;
    --color-background: white;
  }

  [data-theme="dark"] {
    --color-text: white;
    --color-background: black;
  }
`;
```

ThemeProviderでドキュメント側に __data-theme="dark"__ の設置をしているので、CSS側では簡単にVariablesをしてして、それを読み込ませるだけ。

使う側では `color: var(--color-text);` のように書くだけで良い。

## モードを切り替える

モードを切り替える際は、ThemeContextで作った __toggleColorMode__ を呼び出すだけ。

```JSX
import React, { useContext } from "react";
import { ThemeContext } from "./ThemeProvider";

export default function ToggleTheme() {
  const { colorMode, toggleColorMode } = useContext(ThemeContext);

  return (
    <label>
      <input
        type="checkbox"
        checked={colorMode === 'dark'}
        onChange={() => toggleColorMode()}
      />{' '}
      Dark
    </label>
  );
}
```

## まとめ

ダークモードが本当に良いか否かの議論はあるものの、個人的には好きなのでまぁ良いかなって感じに作ってみた。

完全に余談だけど、実装自体は簡単だったが、ダークモードは色が限られるのでデザインが難しいと感じた。

> コックスによれば、読みやすさにとって重要なのは、配色よりも文字と背景のコントラストを強くすることだという。通常モードでもダークモードでも、コントラストが同じなら、おそらく読みやすさに違いはない。しかしわたしたちは、白い背景に黒い文字という組み合わせに慣れているため、通常モードのほうが、やや読みやすく感じるかもしれないとコックスは話す。

こんな感じに読みやすいようなデザインをするのって本当に難しいと今回実装しながら思った。

[How to add dark mode to a Gatsby site](https://www.joshwcomeau.com/react/dark-mode/)
[「ダークモード」は、本当に“目に優しい”のか？](https://wired.jp/2019/10/05/dark-mode-chrome-android-ios-science/)

Next.jsでブログにダークモードを作ったので簡単に解説する

 ダークモードっていいよね

## はじめに

Next.jsの __9.0__ から登場した __API Routing__ を使って、簡単なAPIを作ってみた。
そのAPIをBFFとして使ってみたので使い方を紹介する。

## API Routingとは

__API Routing__ とはNext.jsで簡単にAPIを作れる機能のこと。
既存のNext.jsのルーティングのように、APIのルーティングもディレクトリの構造で書ける。

```text
pages
 |-- api
 |    |-- posts
 |    |   |-- [slug].tsx
 |    |   |-- index.tsx
 |-- posts.tsx
 |-- index.tsx
 |-- _app.tsx
 |-- _document.tsx
```

上記のように __pagesの下にapiというディレクトリをおくだけて良い__ 。　とても簡単に書ける。
この例だと `/api/posts` と `/api/posts/[slug]` という２つのAPIが作れる。

### 実際の中身

`/api/posts` はContentfulから全てのポストをとってくるAPIだとして書いてみると

```typescript
import type { NextApiRequest, NextApiResponse } from "next";

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const entries = await client.getEntries({
    content_type: "post",
  });

  res.statusCode = 200;
  res.setHeader("Content-type", "application/json");
  res.end(JSON.stringify(entries.items.map((item) => convertPost(item))));
};

const convertPost = (item) => {
  return {
    title: item.fields.title,
    subtitle: item.fields.subtitle,
    body: item.fields.body,
    slug: item.fields.slug,
    publishedAt: item.fields.publishedAt,
  };
};

```

基本的にNodeのAPIサーバーのように書くことができる。
返す値は基本的にJSONにしているが、中身は自分のクライアントに合わせて自由に書けば良い。

### パラメーター付きのAPI

例えば、Contentfulから指定した条件に一致したポストだけを返すAPIを作るとしよう。
`/api/posts/[slug]` というAPIを作るとした場合、このAPIはパスで指定した __[slug]__ でポストを探すAPIになる。

```typescript
import type { NextApiRequest, NextApiResponse } from "next";

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const entries = await client.getEntries({
    content_type: post,
    "fields.slug": req.query.slug,
  });

  res.statusCode = 200;
  res.setHeader("Content-type", "application/json");
  res.end(JSON.stringify(convertPost(entries.items[0])));
};

const convertPost = (item) => {
  return {
    title: item.fields.title,
    subtitle: item.fields.subtitle,
    body: item.fields.body,
    slug: item.fields.slug,
    publishedAt: item.fields.publishedAt,
  };
};
```

__req.query.slug__ でパスで指定した __[slug]__ を取得することができる。
この先の流れは同じく、必要な形に合わせて返してあげるだけで良い。

## 注意点

このブログでもこの __API Routing__ を使ってSSGで作ってるが、いくつか注意する点がある。

- 本当のAPIとしては微妙
- ホスティング先によっては使えない

### 本当のAPIとしては微妙

API Routingとはしてるが、個人的に __WEB APIとして使うのは非推奨__ 。

> Next.jsはあくまでReactを用いること前提のフレームワークであり、APIルーティングはおまけ程度のものです。リクエストメソッドのフィルタリング、リクエストボディのバリデーションなどもすべて自前で記述しなければならないため、本格的なWeb APIサーバを開発するには向きません。

[Qiitaブログ | web-apiフレームワークではないので機能的に貧弱](https://qiita.com/jagaapple/items/faf125e28f8c2860269c#web-api%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%AE%E3%81%A7%E6%A9%9F%E8%83%BD%E7%9A%84%E3%81%AB%E8%B2%A7%E5%BC%B1)

例えば、DBから値を取得したり、認証の処理を行ったり、といったビジネスロジックが多く含まれるようなAPIが必要な場合は、 __API Routing__ は向いてない。 Reactベースではあるので書こうとすれば書けるかも知れないが、あまりおすすめはできない。

個人的にNEXT.jsのAPIは __BFFとして使う__ ことが最適だと思っている。
[BFFってなに？](https://parkpark.dev/posts/what-is-bff)

クライアントサイドで必要なAPIをラップして、使いやすい形にして返してあげる、それ以上のことはしない、ということが自分の使い方。まさにBFFとして使っている。
上に書いたサンプルコードもContentfulのSDKは使っているが、基本的には __ContentfulのAPIを叩いて、形を変えて返す__ だけの __APIコンポジション__ を実現したBFFになる。

### ホスティング先によっては使えない

__API Routing__ は __SSR__ として実現されるので、ホスティング先がSSRを対応してなければ使えなくなる。
実際にnetlifyの場合はサポートしてなく、 __API Routing__ を使えない。

自分ももともとnetlifyを使っていて、この機能を試すためにvercelに移行した。
基本的なホスティングしかしないのでそこまで使い方は違いないが、やはりNEXT.jsの開発元なのでAPI Routingもサポートしてくれていた。


Next.jsのAPIをBFFとして使ってみた。簡単な使い方と注意点を書いてみる。

Next.jsのAPIを使ってみた

## BFFとは

BFF(Backends For Frontends).
名前の通り、フロントエンドのためのバックエンド。 デスクトップやモバイルなどの __クライアントごとに実装されたAPI Gateway__ のこと。

ほんで、 __API Gateway__ はまたなに？

### API Gateway

__API Gateway__ はクライアント（フロントエンド）とバックエンドのレイヤーに存在して、以下のような機能を持っている。

- リクエストのルーティング
- APIを複数呼び出して、結果をまとめる
- プロトコル変換
- 認証・認可
- リクエストの制限
- キャッシュ
- ログの出力
- etc...

上記の全てを実装してからこそAPI Gatewayになるわけではない。
認証や認可はSSOなどを実現するために共通して切り出すこともあったり、ルーティングはロードバランサを使って実現したりすることもよくある。

__BFF__ はこの `API Gateway` の役割の中で、 __APIを複数呼び出して、結果をまとめる__ 、つまり __APIコンポジション__ をメインとしていると思う。
なぜなら、BFFは __クライアントによってBFFのレスポンスが大きく変わる__ 。

同じマイクロサービスのAPIを使うとしても、クライアントごとに欲しがるレスポンスの形が違うから。

## BFFのメリット

__BFF__ を置くことによって得られるメリットを一つは __パフォーマンスの改善__ にある。
BFFだけでなく、APIコンポジションを行う __API Gateway__ なら共通して得られるメリット。

BFFを置かなく、クライアントでAPIコンポジションを行うことを想定してみよう。
その場合、クライアントは複数のAPIを叩くことになり、大量のリクエストをすることになる。
BFFでAPIコンポジションを行うのであれば、クライアントからのリクエストは __1回__ になるので簡単。
それにクライアントで欲しがる形でデータを返してくれるのでクライアント側でデータの操作がなくなるので、コードがシンプルになる。

また、 __BFF__ を置くと、__クライアントからAPIを隠せる__ ようになる。
複数のAPIが存在する際に、それらのAPIを直接叩いたり、データをまとめるのはBFFで行われるのでクライアントではBFFの位置だけ知っていればデータがもらえる。

クラインととAPIをもっと厳密に切り離すことができるので、メンテナンスはより簡単になる。

## BFFのデメリット

BFFも一つのマイクロサービスなので、 __BFF自体の開発コスト__ もやはりかかってしまう。
基本的にBFFにはビジネスロジックはなく、簡単な操作しかないが、マイクロサービスである以上は当然テストも必要になってくる。

しかし、個人的に会社で開発する際に　__BFF自体の開発コスト__　はそこまで気になりはしなかった。
上にも書いたが、__BFFにはビジネスロジックはない__ ので、テストやE2Eも簡単で、実装自体も結構簡単に済むことが多いイメージ。

## 注意点

BFFはクライアントと近いので下手するとクライアントに大きい影響が出てしまう。
基本的に全てのサービスがそうだが、BFFは特に実装の漏れや不具合が __ユーザに直接的な影響をもたらしてしまう__ ので注意が必要。

また、BFFは複数のAPIを叩くので、一部のデータが欠落しているケースは考慮して設計しないといけない
あるAPIのレスポンスがあまりにも帰ってこない場合は、その他のデータだけを返すとか、そもそも早めにエラーを返すかなどは考えるべき。これもBFFに限っての話してはないが、常に意識はする必要がある。

### 参考
[Microservices Patterns](https://www.manning.com/books/microservices-patterns)

[microservices.io - apigateway](https://microservices.io/patterns/apigateway.html)


BFFが何でなぜ使うのか、メリットとデメリットを知ってる限り書いてみる。

BFFってなに？

ContentfulのSDKの使い方をまとめる。
職場でもContentfulは使ってるからほぼ自分用

## 対応ブラウザーとNode

Supported browsers and Node.js versions
- Chrome
- Firefox
- Edge
- IE11
- Safari
- node.js (LTS)

モダーンブラウザーは対応していて、IE11以上は対応している。
他のブラウザーや古いNode.jsでも一応対応しているようだが、厳密なテストはしてなく、自動テストは通る程度のメンテーをしているようなのでもしかするとちゃんと動かないかも。

## インストール

npmやyarnなどのパターン

```shell
npm install contentful
```

直接差し込むパターン。
特定のバージョンを使う場合は、 `@latest` の代わりに `@8.2.0` のようなバージョンを指定するだけ。
[Contentful Realase](https://github.com/contentful/contentful.js/releases)

```javascript
<script src="https://cdn.jsdelivr.net/npm/contentful@latest/dist/contentful.browser.min.js"></script>
```

IE11や、古いブラウザーの対応が必要な場合は、 `contentful.browser.min.js` の代わりに、 `contentful.legacy.min.js` を指定する。

## CDAを使おう
CDA(Content Delivery API)は、ContentfulのAPIの一つで、内容を取得する際に使うAPI。
記事を読み込んだり、Contentfulから何かをとってくるAPIなのでもっともメインとなる。
`Preview API` というDraftまで扱えるAPIがあるが、基本ベースはCDAと同じで、APIのエンドポイントとアクセストークンだけが変わるので必要によって簡単に使える。

とりあえず、CDAを使うためのClientを作る。
clientを作るには `space` と `accessToken` は必須。

```javascript
const client = require("contentful").createClient({
  space: "spaceId",
  accessToken: "accessToken",
});
```

`createClient` で指定できるオプション一覧。

| Name             | Default                   | Description |
| ---------------- | ------------------------- | ---------- |
| accessToken      |                           | 必須        |
| space            |                           | 必須        |
| environment      | 'master'                  |            |
| host             | 'cdn.contentful.com'      |            |
| basePath         | ''                        | カスタムゲートウェイ/プロキシ用 |
| httpAgent        | undefined                 | [axios request config documentation](https://github.com/mzabriskie/axios#request-config)を参考  |
| httpsAgent       | undefined                 | [axios request config documentation](https://github.com/mzabriskie/axios#request-config)を参考  |
| adapter          | undefined                 | [axios request config documentation](https://github.com/mzabriskie/axios#request-config)を参考  |
| headers          | {}                        |  |
| proxy            | undefined                 | [axios request config documentation](https://github.com/mzabriskie/axios#request-config)を参考  |
| resolveLinks     | true                      | falseにすると、link Resolvingが解除される  |
| removeUnresolved | false                     | 未解決のリンクに対する応答からフィールドを削除する。 |
| retryOnError     | true                      | デフォルトだと、500サーバーエラーや、429 Rate Limitになったらリトライする |
| logHandler       | function (level, data) {} | errors, warningsを処理する際に使う |
| requestLogger    | function (config) {}      | リクエストごとに呼ばれる     |
| responseLogger   | function (response) {}    | レスポンスごとに呼ばれる    |

長くて書ききれなかったが、 `header` には以下の２つが追加される。

```
- Content-Type: application/vnd.contentful.management.v1+json
- X-Contentful-User-Agent: sdk contentful.js/1.2.3; platform node.js/1.2.3; os macOS/1.2.3 (Automatically generated)
```

## Clientからデータを取ってみる

entryIDを指定する方法

```javascript
client.getEntry('<entry_id>')
```

content_typeを指定して、複数のentryを取得

```javascript
client.getEntries({
  content_type: "content_type"
})
```

### Order

特定のフィールドでsortする。

```javascript
client.getEntries({
  order: 'sys.createdAt'
})
```

複数指定もできる

```javascript
client.getEntries({
  order: 'sys.createdAt,sys.id'
})
```

降順のsort

```javascript
client.getEntries({
  order: '-fields.publishedDate'
})
```

orderに指定できるフィールドは `String` , `Date` , `Integer` , `Boolean`

### limit, skip

DBのoffet, limitと同じようなパラメータ
ページネーションなどでよく使われる。

```javascript
client.getEntries({
  skip: 100,
  limit: 200,
  order: 'sys.createdAt'
})
```

`limit` はデフォルトで100, 上限は1000まで。

### select

取得するフィールドを絞る。
カンマ区切りで取得するフィールドを指定できる。

```javascript
client.getEntries({
  select: "fields.slug,sys.createdAt",
});
```

### search

あるフィールドの値を完全一致で取得する。

```javascript
client.getEntries({
  "sys.id": "id"
});
```

`[ne]` をつけると不一致な物を取得できる。

```javascript
client.getEntries({
  "sys.id[ne]": "id",
});
```

上記の２つはテキストフィールドではサポートされてない。
テキストフィールドで扱いたい場合は `content_type` と組み合わせる必要がある。

指定したフィールドが配列の場合、配列の中で、一つでも一致するEntryを取得できる。
配列の `[ne]` は、複数の中で一つでも一致しないものだけを返す。
検索対象が `fields` の場合は、 `content_type` を指定する必要がある。

複数指定した中で、全部一致したEntryだけを返すのは `[all]` を使う

```javascript
client.getEntries({
  "content_type": "post",
  "fields.tags[all]": "flowers,accessories",
});
```

複数指定した中で、一つでも一致したEntryだけを返す

```javascript
client.getEntries({
  "content_type": "post",
  "fields.tags[in]": "flowers,accessories",
});
```

複数指定してフィルタリングする

```javascript
client.getEntries({
  "content_type": "post",
  "fields.tags[nin]": "flowers,accessories",
});
```

指定したフィールドに何かが入っているか否かでフィルタリングする。
何かの値が入っていたら `true` 、 何も入ってないまたはフィールドが定義されてない場合は `false` になる。

ちなみに `True` `False` などの大文字で入れるとダメみたい。

```javascript
client.getEntries({
  "content_type": "post",
  "fields.tags[exists]": true,
});
```

### Ranges

範囲の指定は以下の４つ。
検索対象のフィールドは `Date` や `Number` 型で指定する。

- `[lt]`  : より小さい
- `[lte]` : 以下
- `[gt]`  : より大きい
- `[gte]` : 以上

### text query

queryで指定すると、全フィールドを対象に検索をかけられる。
グローバルな全文検索は全てのロケールからテキストや記号の検索ができる。
テキスト検索は大文字と小文字の区分をしないので、予想以上のEntryがくるかも知れない。
指定できる文字列は２文字以上。

```javascript
client.getEntries({
  query: "design",
});
```

`[match]` を使うと、特定のフィールドで文字列検索ができる。

```javascript
client.getEntries({
  "fields.website[match]": "design",
});
```

## まとめ

チートシートって書いてあるが、全ての仕様を網羅してるわけではなくなった。
でもよく使うのはCDAで、その中で自分でよく使えそうな機能だけはまとめてみた。
追加で必要になったりするとアップデートしていく予定。


JavascriptでContentfulのSDKのドキュメントと使い方を色々書いてみる

Contentfulチートシート

### CSR（Client-Side Rendering）

> Client-side rendering (CSR) means rendering pages directly in the browser using JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server.

レンダリングをClient側に任せる方法。
`React` や `Vue` などのJavaScriptライブラリやフレームワークを使う場合は特に意識せずに、自然に使う方法でもある。

初期ロード時にデカイJavascriptを送信するし、レンダリングもJavascriptで行われるので処理量が増えて、__ページロードされるまで時間がかかってしまう__。
最近はクライアント側のデバイスの性能もよくなり、Javascriptエンジンの性能も凄くよくなったので個人レベルではあまり気にしなくても良いかも知れないが、デバイスの性能によって表示時間の問題も考えられる。
ReactではlazyとSuspenseを使うとコードの分割ができるので初期ロードやレンダリングの問題を少しは解消できるかも。

しかし、ユースケースにもよるが、 __SEOを前提__ にしているサイトであればCSRは弱点がある。

```html
<html>
  <head>
    <title>sample</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/js/bundle.js"></script>
  </body>
</html>
```

CSRはクライアントでレンダリングをするので初期ロード時は上のようなページになる。
その結果、Googleさんが拾ってくれなくなるのでSEOではかなりのマイナス要素になってしまう。
これは全てのSPAやCSRのサイトでは共通している課題でもあるが、今のところ簡単にSEO対策をするのは難しいと思う。

最近のGoogleのイベントとかでもSPAのSEOの話は多く上がってきていて、今後はSPAやCSRのメディアもちゃんとクローリングしてくれることを期待しているが、今のところはSEOを念頭にしていれば他の方法を試すべきではないかな

ログインが必要なサービスや、ユーザーごとにカスタマイズされているサービスの場合はSEOの対策はいらないのでCSRでも十分。

### SSR（Server-Side Rendering）

> Server rendering generates the full HTML for a page on the server in response to navigation. This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response.

CSRの弱点を補うため、クライアント側でなく、サーバー側でレンダリングをして、クライアントに返す方法。
ユーザーのデバイスの性能に依存しないのでレンダリングの問題は一定なくなるが、サーバーで処理してレンダリングさせるので最終的なレンダリングの時間は少なからずある。

SEOの観点ではCSRのような問題はなくなるが、SSGに比べると微妙かも。
パフォーマンスでもSSGより遅いし、そもそもSSRを実現するためには別途レンダリングのサーバーが必要になるので少し不便。

何より、Next.jsを使うなら __SSRでできることはSSGでもできる__ ので個人的には好きではない。
昔は違ったかも知れないが、Nextの９以降からはSSGが非常に簡単に実現できるので特に凄くこだわりがなければSSGを使った方が良いかもと思っている。

余談だが、あまりSSRのイメージがつかないかも知れないが、ローカルで `yarn dev` とかで立ち上げる開発環境がまさにSSRになってるので

### SSG(Static Site Generation)

SSGはビルド時にHTMLを構築する方法。
ビルド時に `data fetching, templating and routing` などのユーザーのリクエストを事前に行い、HTMLファイルとしてexportする。

HTMLにしておくメリットとしてはCDNに載せてキャッシュさせるとロードやパフォーマンスは上記の２つと比べると凄く早い。結果物はただのHTMLなので個別ページは小さくもなるし、SEOの対策も簡単。
セキュリティも複雑なロジックがなくなるので対策も簡単 or 要らないかも知れない。

Next.jsでは __Dynamic routing__ や、 __dyanamic contents__ SSGで簡単に扱えるのでSSRでやっていたことは大体できる。

ブログや、メディアを構築するなら `SSG` を最初に検討すべきだと思う。

しかし、個人レベルではなく、事業レベルのサイトで数万やそれ以上のページを持ったサイトの場合、事前に全てのページを全部レンダリングするSSGは現実的ではない。
また、SNSのように複数人が使い、更新が激しい場合はSSGではビルド時だけ `data fetching` を行うため、上手く情報を届けられなくなる。

Next.jsでは __fallback__、__ISR__ で解決できるので事業レベルでのサービスでもSSGは検討してみる価値は十分あるのではないかと思う。

[参考: google develpers rendering-on-the-web](https://developers.google.com/web/updates/2019/02/rendering-on-the-web)

Next.jsでCSR,SSG,SSRを簡単に説明する。

今更CSR,SSG,SSRをざっくり説明


## Reactに比べて良いところ
基本的にはReactと書き方は大体一緒だが、比較してよくなってる部分もある。
`Built-In CSS Support` や、`Internationalized Routing`などReactにはない特色もあるが、今回は特に気に入った何個かだけ紹介する。

[Next.js公式ページ](https://nextjs.org/)

## File-system Routing
例えば、以下のようなpathでroutingするとしたら、

```text
/
/about
/posts
/posts/[slug]
```

`[slug]` は記事のIDで、動的に変わるもの。

### Reactの書き方
`React Router` を使って書いてみた。

```tsx
import { BrowserRouter, Switch, Route } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Switch>
        <Route path="/" exact children={<Index />} />
        <Route path="/about" children={<About />} />
        <Route path="/posts" children={<Posts />} />
        <Route path="/posts/:slug" children={<Post />} />
      </Switch>
    </BrowserRouter>
  );
}
```

Componentの中にRoutingのパスなどの設定を書く事になる。
個人的にこの書き方もわかりやすくて嫌いではないが、Routingの処理はComponentとして書くべきなのか？という疑問は少しあった。

### Next.jsの書き方
NextではFile-treeでRoutingができる。
上記と同じRoutingをしてみると、

```text
src
 |-- pages
     |-- posts
     |    |-- [slug].tsx
     |    |-- index.tsx
     |-- about.tsx
     |-- index.tsx
     |-- _app.tsx
     |-- _document.tsx
```

Next.js 9.1以降ではsrcディレクトリがサポートされるのでpagesもsrcの下においている。
パスを特に書く必要なく、ファイルを置くだけで書ける。
個々のファイルがパスを意味して、各パスのTop-level Componentとして使える。

#### Linking to dynamic paths
`[slug].tsx` などの動的なパスにアクセスする時に、Linkする方法。

```tsx
import Link from 'next/link'

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

export default Posts
```

## Pre Renderingが簡単
Next.jsは `SSR,SSG` の両方が簡単にできる。
Reactではそもそも `SSG` を試したことすらないのでどれほど簡単にできるかわからないが、Next.jsでは特にそれほどの設定は必要なく、すぐにできる。

```shell
❯ yarn run next build
❯ yarn run next export
```

これでoutというディレクトリに色々生成されるのでoutディレクトリをホスティングサーバーに置くだけでStaticなアプリケーションができる。
SSR, SSGやClient-side-renderingについてはまたいつか。

## まとめ
Reactと比べてNext.jsで特に気に入った機能を何個か載せてみた。
Gatsby.jsはまだ試してみてないのでどっちが使いやすいのかまではわからないが、Next.jsを触ってみた感じ別にGatsby.jsを使わないといけない理由はまだない。
Next.jsと言っても基本は `React + SSGジェネレーター` のような物なのでReact好きの人は試してみてもすぐに書けると思う。

ReactからReact-staticになって、最終的にNext.jsになった話

Reactではなく、Next.jsにした理由

開発を初めて、最初はMaterialUIで書いていたが、色々モヤモヤしてたので移行した。
その中でモヤモヤした点、移行する際に気にしてた点をまとめる。

## Material UIからemotionに移行
当初Material UIで書いていたけど、なんか色々気に入らない。
気に入らない点は２つだった。

- CSS-in-JSの書き方が気に入らない
- Material UIのデフォルトのスタイルが邪魔

### CSS-in-JSの書き方が気に入らない
```css
.text {
  text-align: center;
  font-size: 2rem;
  color: red;
}
```
こんな感じのCSSをMaterialUIを使って、Componentにスタイルを当ててみる。

#### Hooks式
`@material-ui/core/styles` の `makeStyles` を使う。
styleを定義したfunctionを、Componentで呼び出してclassNameに渡してあげる。

```jsx
import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

const useStyles = makeStyles({
  text: {
    textAlign: center,
    fontSize: 2rem,
    color: red
  }
});

export default function StyledText() {
  const classes = useStyles();
  return (
    <p className={classes.text}>
      Test
    </p>
  );
}
```

#### Styled Component式
`@material-ui/core/styles` の `styled` を使う。

```jsx
import React from 'react';
import { styled } from '@material-ui/core/styles';
import Typography from '@material-ui/core/Typography';

const CustomText = styled(Typography)({
  text: {
    textAlign: center,
    fontSize: 2rem,
    color: red
  }
});

export default function StyledText() {
  return (
    <CustomText>Test</CustomText>
  );
}
```

個人的にスタイルのためのComponentを作るのは好きじゃないのでHooks式の書き方を採用。
それで書いてはいたけど、CSS プロパティ名をキャメルで書くのにすごい違和感&不便だった。。
ネットで調べた __このスタイル良さそう！ コピペしよう__ ができない。
レスポンシブの対応も簡単にできるのか@mediaとかではないので若干の違和感がある。

### Material UIのデフォルトのスタイルが邪魔
これは良いところでもあり、悪いところでもあるかも。
Material-UIは単純にCSS-in-JSのライブラリーではないからこれで怒るのは自分が悪いきもするけど、まぁ色々邪魔だった。
確かにあまり気にしなくても簡単に綺麗な画面が作れるのは確かにそうだけど、もうちょっと細かくスタイルをいじるときが問題になっていた。
Material-UIはかなり大きいフレームワークだから思ったよりスタイルを頑張ってくれてたので個人的に今回のブログは自分の勉強目的もあったから自分でスタイルも頑張ってみたいから他のライブラリーを選ぶとした。

## emotionを採用する
そこで色々調べて、何個か候補を出してみて選ぶとした。

1. 諦めてMaterial-UIを使い続ける
2. かの有名なStyled Component
3. emotion
4. tailwind css

そこで1はまぁないでしょと思ってそもそも除外。
上にも書いているが、スタイルだけのためのComponentは個人的に好きじゃないので2も除外した。
4のtailwind cssも一瞬考えたけど、スタイルの勉強にもならないし、これも他プロジェクトでスタイルを共有したりするときに再利用性もないので諦めた。

消去法に見えるが、emotionは結構気に入ったので採用。
それでこのブログは現在emotionでスタイルが書かれている。

### emotionの書き方
emotionの場合、cssのブロックにしてあげてcomponentのcssに渡してあげる。
Sassで書けるので非常に書きやすい。
cssのpropsはReactにはないので色々設定しないといけないけど、他のCSS-in-JSのライブラリーとあまり差はないので気になるほどではなかった。
Styled Componenet見たいにCompoenetを作る方法もあるが、好みじゃないので使ってない。

```
import React from 'react';
import { css } from "@emotion/react";

const text = css`
  text-align: center;
  font-size: 2rem;
  color: red;
`

export default function StyledText() {
  return (
    <p css={text}>
      Test
    </p>
  );
}
```

vscodeだとStyled Component用のプラグインを入れたらスタイルの補完もしてくれるので非常に満足しなが楽しく書いている。


MaterialUIからemotionに移行した話

巡りめぐってemotionを使ってみた

Reactを書きたくてとりあえずブログを作ったので作るまでの過程をもろもろ書いていきます。

## 背景
React書きたい！ Jamstackやってみたい！
から初めて正直何も決まってなく、とりあえずReactで書き始めた。
会社で担当しているプロダクトのフロントの改善に持っていく知識を身につけるためでもある。

### 技術選定(初期）
```
- フロント: React
- デザイン: MaterialUI
- CMS: MicroCMS
- デプロイ: 決めてない
```
Reactを書きたかったのでReactでとりあえず書き始めた。
デザインに関してはCSSザコなのでMaterialUIにしていた。
CMSは流行りのMicroCMSを検討していて、デプロイ先は特に決めずにスタート。
Topページを完成する部分まではこの構成でしていた。

### デザイン変更
MaterialUIから少しモヤモヤ感を感じ、emotionに移行した。
詳しい話は別のポストに書きます。

[スタイル移行した話](http://parkpark.dev/posts/hello-world-material-to-emotion)

### nextJSに移行(現行)
```
- フロント: nextJS
- デザイン: emotion
- CMS: Contentful
- デプロイ: netlify
```

記事のページを作り終わって、そろそろデプロイして公開することを目指していた。
Jamstackをやったことがなく、Reactで何とかプラグイン入れれば良いでしょー的な考え方だったが、難しかったので少し変えようと思ってまた技術選定をした。

最初検討していたのは `React Static` だった
[React Static](https://github.com/react-static/react-static)
Githubの星も１万個近くあって、良い！と思って導入。
動かすところまでもでき、ちゃんとstaticなページのビルドまでもできたが、ちょっと書き方が難しかった。
static buildのためにAPIコールする部分とかがもうちょっと簡単に書きたかったのでまた他を参考。

そこで最終的にnextJSに落ち着いた。
pageの切り方、staticPropsの渡し方が凄くわかりやすく、気に入った。
React + α的な書き方だったので移行も簡単だった。

CMSやnetlifyの詳しい話は別にします。
