
（完全に自分用のメモです。）

TypeScript+React+Redux を使うときに気に入って使っている[typesafe-actions](https://github.com/piotrwitek/typesafe-actions)。
意外なところでハマりポイントがありました。

## Reducer で Action の型情報が見れない

よくある Reducer。

```typescript
export const weatherReducer = (
  state: WeatherState = initialState,
  action: Action
): WeatherState => {
  switch (action.type) {
    case getType(actions.weatherSetAction):
      return Object.assign({}, state, { weather: new Weather(action.payload) });

    case getType(actions.weatherErrorAction):
      console.error(action.payload.message);
      return state;

    default:
      return state;
  }
};
```

ところが`action.payload`の型情報が正しく取れていません。なぜだろう。。。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/typesafe-actions1.png)

エラーの内容はこちら。

```txt
TS2339:
Property 'payload' does not exist on type 
'{ type: string; payload: { lat: number; lng: number; }; } | 
 { type: string; payload: Response; } | 
 { type: "@@weather/ERROR"; payload: Error; } | 
 { type: "@@map/READY"; }'.
  Property 'payload' does not exist on type '{ type: "@@map/READY"; }'.
```

Action の型定義は一見良さそうなので、最初は何が原因かわかりませんでした。

> (追記: 2019/01/23)
> というか型定義良くない。`type: string`になっている。Blog 用にエラーを整形したら気づいた。エラーメッセージもっと冷静に読まないと。

## ActionType に動的な文字列を使ってはいけない

原因はこれでした。ActionType を`PREFIX`を使ったテンプレート文字列で定義している部分。

```typescript
// constants.ts
const PREFIX = "@MyApp";
export const MAP_READY = `${PREFIX}/READY`;
export const WEATHER_GET = `${PREFIX}/GET`;
export const WEATHER_SET = `${PREFIX}/SET`;
export const WEATHER_ERROR = `${PREFIX}/ERROR`;
```

公式ドキュメントにも書いてありました。

- [typesafe-actions: The Actions](https://github.com/piotrwitek/typesafe-actions#--the-actions)

> PRO-TIP: string constants limitation in TypeScript
> ...

TypeScript には文字列の定義に関する制限事項があってだね。テンプレート文字列などで動的に文字列を組み立てた場合、型情報が全部`string`になってしまって、reducer の case の中の型情報が壊れるよ。（超訳）

```typescript
// Example file: './constants.ts'

// WARNING: Incorrect usage
export const ADD = prefix + 'ADD'; // => string
export const ADD = `${prefix}/ADD`; // => string
export default {
   ADD: '@prefix/ADD', // => string
}

// Correct usage
export const ADD = '@prefix/ADD'; // => '@prefix/ADD'
export const TOGGLE = '@prefix/TOGGLE'; // => '@prefix/TOGGLE'
```

（公式ドキュメントから抜粋）

という訳で、正しいやり方は普通に文字列だけで ActionType 定義すればいいだけでした。

```typescript
// constants.ts
export const MAP_READY = "@MyApp/READY";
export const WEATHER_GET = "@MyApp/GET";
export const WEATHER_SET = "@MyApp/SET";
export const WEATHER_ERROR = "@MyApp/ERROR";
```

なるほど、TypeScript の制限。
勉強になりました。


typesafe-actionsのActionTypeに動的な文字列を使ってはいけない


この記事は[React.js その 2 Advent Calendar 2018](https://qiita.com/advent-calendar/2018/react2) 8 日目の記事です。

半年くらい前に、[React \+ Redux \+ redux\-observable \+ TypeScript の実践的サンプル](https://blog.mitsuruog.info/2018/03/react-redux-observable-typescript)という記事を書いたのですが、Redux の action と reducer の部分の型があまりうまく定義できてなかったので、個人的  に課題だと感じていました。

今回はその部分を[typesafe-actions](https://github.com/piotrwitek/typesafe-actions)を使って型安心に実装する方法の紹介です。

プロジェクト全体のコードはこちらを参照してください。

- [mitsuruog/react\-redux\-observable\-typescript\-sample: A sample application for React \+ redux\-observable \+ TypeScript](https://github.com/mitsuruog/react-redux-observable-typescript-sample)

## 以前のコード

以前のコードは Action に interface を定義して、型が必要な Reducer などの部分でこの interface を使って Any 型をキャストする方法を取っていました。

```typescript
// Actionでinterfaceを定義して
interface CoolAction {
  isSuperCool: boolean;
  payload: {};
}
```

```typescript
// Reducerの中でキャストする
switch (action.type) {

  case COOL_ACTION:
    return Object.assign({}, state, {
      cool: new CoolModel((action as CoolAction).payload)
    });

  default:
    return state;
}
```

この場合、どうしても Action と Reducer の間で Any 型となってしまい、型安心とは言えない状態でした。
最近になって[react\-redux\-typescript\-guide](https://github.com/piotrwitek/react-redux-typescript-guide#redux)を読んでいたら、Redux Store 周りを型安心にする方法が載っていたので試してみました。

## typesafe-actions を使って型安心な Redux Store を実装する

### Action の定義

まず Action を定義します。以前を同じように`createAction`をつかって型を定義していきます。
`resolve`の中に Action の payload を渡します。これが後に Reducer などで利用されます。

```typescript
import { createAction } from "typesafe-actions";

import { WEATHER_GET } from "../constants";

export const weatherGetAction = createAction(
  WEATHER_GET,
  (resolve) => (lat: number, lng: number) => resolve({ lat, lng })
);
// これと同じ
// {
//   type: WEATHER_GET,
//   payload: { lat: number, lng: number },
// }
```

> typesafe-actions には`action`というもう少し簡単に Action を定義できる関数がありますが、
> この場合、`getType`や`isActionOf`などの Helper 関数と一緒に使えない Action となります。
> 個人的には、Helper 関数を使わない理由があまりないので、面倒でも`createAction`を使うことをおすすめします。

### Reducer で Action の型を使う

次に Reducer で Action の型の使い型です。
`ActionType`のジェネリックに Action の定義を渡すと、Action の実行結果の型が返ってきます。これを Action の型として利用します。

```typescript
import { ActionType, getType } from "typesafe-actions";

import * as actions from "../actions";

type Action = ActionType<typeof actions>;
// 実際のActionには複数のActionのUnion typeが設定されている
// {  type: WEATHER_GET, payload: { lat: number, lng: number } } |
// {  type: WEATHER_GET, payload: { weather: Response } }
```

`ActionType`の中身については非常に難しい部分ですが、簡単に説明すると TypeScript の`ReturnType<T>`を使って型情報を取得しています。

`ReturnType<T>`は`T`に渡された関数を実行してその戻り値の型情報を取得するものです。

例えば、上の actions の中に`weatherGetAction`と`weatherSetAction`があった場合、
`ActionType<typeof actions>`の結果は`weatherGetAction | weatherSetAction`のような Union type になります。(実際には`weatherGetAction`関数の戻り値の型です。)

次に Action の型情報を取得できたので、これを Reducer の Action の型定義として使います。
Type の判定は`getType`を使うことで型安心に判定することができます。

```typescript
export const weatherReducer = (state: WeatherState = initialState, action: Action): WeatherState => {

  switch (action.type) {

    case getType(actions.weatherSetAction):
      // このActionの型は { type: WEATHER_GET, payload: { lat: number, lng: number} }
      return Object.assign({}, state, { weather: new Weather(action.payload) });

    ...

    default:
      return state;
  }
};
```

以上が基本的な流れです。

## おまけ、redux-observable と一緒に使う

[typesafe-actions に redux-observable についての記載](https://github.com/piotrwitek/typesafe-actions#--the-async-flow)があるのですが、これだけだとうまく行かなかったので、うまく行かなかったポイントを紹介します。

### Epic の実装

まず、Reducer と同じ方法で Action の型情報を取得しておきます。
Epic の実装は上の typesafe-actions のガイドの通りに実装すれば大丈夫です。`isOfType`と`getType`を使って型安全に実装していきます。

```typescript
// ActionはReducerと同じように取得したActionの型情報
export const weatherGetEpic: Epic<Action, Action, RootState> = (action$, store) =>
  action$.pipe(
    filter(isOfType(getType(actions.weatherGetAction))),
    switchMap(action =>
      ...
    )
  );
```

### Store の実装

Store の実装の部分は少し変更が必要です。
次のように実装した場合、コンパイル時にエラーがでます。

```typescript
const epicMiddleware = createEpicMiddleware();
// ちょー長いActionの型定義 is not assignable to parameter of type 'Epic<Action<any>, Action<any>, void, any>'.
```

Action と State の型情報がうまく渡っていないようなので、ジェネリックで型情報を渡すようにするとコンパイルできるようになります。

> もしかすると自分の Epic の型定義がどこか間違っているだけかもしれないが。。。

```typescript
const epicMiddleware = createEpicMiddleware<Action, Action, RootState>();
```

これで redux-observable と一緒に使っても型安心になりました。

## まとめ

説明割愛してしまった部分もありますが、実際に動作しているコードは[GitHub](https://github.com/mitsuruog/react-redux-observable-typescript-sample)を見てください。

> typesafe-actions で意外なハマりポイントがあったので、こちらにも目を通しておくといいです。
>
> - [typesafe\-actions の ActionType に動的な文字列を使ってはいけない \| I am mitsuruog](https://blog.mitsuruog.info/2019/01/dont-use-dynamic-string-for-typesafe-actions)


typesafe-actionsを使って型安心なRedux Storeを実装する


タイトル長くてすみません。

ひと昔前までは、[react-create-app](https://github.com/facebook/create-react-app)で作成したプロジェクトの webpack.config を上書きするには、`eject`するしか方法がなかったのですが、現在は [react-app-rewired](https://github.com/timarney/react-app-rewired)を使うことで上書きが可能です。

> この方法を使った場合、react-create-app が提供するツールの動作保証対象外となります。つまり、これ以降発生した問題は自己責任で解決しなければなりません。ご注意ください。

紹介する内容は、こちらの Github で見ることができます。

- <https://github.com/mitsuruog/create-react-app-typescript-rewired-styleguidist>

## react-app-rewired を導入する

基本的にはリポジトリにある README.md の通りに導入します。より具体的な例については後で少し紹介します。

### react-app-rewired をインストールする

まず npm モジュールをインストールします。

```sh
npm install react-app-rewired --save-dev
```

### プロジェクトのルートディレクトリに`config-overrides.js`を作成する

プロジェクトのルートディレクトリに`config-overrides.js`を作成します。とりあえず、ファイルの中身は公式ドキュメントのままにしておきますが、詳しくは後で紹介します。

```js
module.exports = function override(config, env) {
  //do stuff with the webpack config...
  return config;
};
```

### `package.json`の`sctipts`を変更する

`package.json`を変更します。

基本的には`react-scripts`の部分を`react-app-rewired`に変更すればいいのですが、TypeScript プロジェクトの場合は`--scripts-version`に起動スクリプトの名前が必要です。これは、react-app-rewired の内部で TypeScript 用の起動スクリプトにスイッチするために利用しています。

```diff
"scripts": {
-  "start": "react-scripts start",
+  "start": "react-app-rewired start --scripts-version react-scripts-ts",
-  "build": "react-scripts build",
+  "build": "react-app-rewired build --scripts-version react-scripts-ts",
-  "test": "react-scripts test --env=jsdom",
+  "test": "react-app-rewired test --env=jsdom --scripts-version react-scripts-ts",
},
```

### 動作確認する

最後にプロジェクトの開発用サーバーの起動とビルドの確認をします。

```sh
# 開発用サーバーの起動
npm start

# ビルド
npm build
```

正しく動いているようであれば、ひとまず導入は完了です。

## `config-overrides.js` をカスタマイズする

上の内容では元の Webconfig のままなのでカスタマイズする必要がありますが、その内容は**中〜上級者向け**です。カスタマイズのプロセスは次の通りです。

1. ここから[config-overrides.js のテンプレート](https://github.com/timarney/react-app-rewired#extended-configuration-options)を取得する
2. 設定変更用の関数(慣例で`rewire(再結線する)`と呼ぶことが多い)を作成する
3. rewire 関数を config-overrides.js に追加する

`config-overrides.js`のテンプレートは大まかに次のようなファイルになっています。
いくつかカスタマイズできるポイントがあるのですが、webpack.config のカスタマイズだけであれば、`webpack`の部分だけ注視していればいいと思います。

```js
module.exports = {
  // 開発サーバーのカスタマイズポイント
  devServer: function (configFunction) {
    return function (proxy, allowedHost) {
      // デフォルト設定の開発サーバーを作成する
      const config = configFunction(proxy, allowedHost);

      // この辺でカスタマイズする

      return config;
    };
  },
  // `npm test`のカスタマイズポイント
  jest: function (config) {
    // この辺でカスタマイズする

    return config;
  },
  // webpack.configのカスタマイズポイント
  webpack: function (config, env) {
    // この辺でカスタマイズする

    return config;
  },
};
```

### (実践例)Sass 設定のカスタマイズ

では、既存の webpack.config の Sass 設定をカスタマイズして`sass-loader`を追加してみましょう。

> `react-create-app`の公式では別の方法が推奨されていますが、自分はこの昔ながらのやり方が好きなのです。

まず、Sass 設定を上書きする`rewireSass`関数を作成します。

```js
// config-overrides.js
const rewired = require("react-app-rewired");

function rewireSass(config) {
  const cssLoader = rewired.getLoader(
    config.module.rules,
    // ここでloaderをフィルタする
    (rule) => rule.test && String(rule.test) === String(/\.css$/)
  );

  // 新しいsass-loaderの設定
  const sassLoader = {
    test: /\.scss$/,
    use: [...(cssLoader.loader || cssLoader.use), "sass-loader"],
  };

  // sass-loaderを追加する
  const oneOf = config.module.rules.find((rule) => rule.oneOf).oneOf;
  oneOf.unshift(sassLoader);

  return config;
}
```

`react-app-rewired`のパッケージに`getLoader`という loader を pick up する関数があるので、これを使って既存の config から上書きするターゲットの loader だけを抽出します。

あとは、コードを見てもらうとわかると思うのですが、普通の JavaScript プログラミングです。
途中、`console.log`などを出しながら途中経過を見てカスタマイズしていきます。

> なので、将来 react-create-app 側の wepack.config が変わったり、Webpack 自体のバージョンが上がった場合は、容易に動作しなくなると思います。

この`rewireSass`関数を`config-overrides.js`に追加します。

```js
// config-overrides.js

function rewireSass(config) {
  ...
}

module.exports = {
  // 開発サーバーのカスタマイズポイント
  devServer: function (configFunction) {
    return function (proxy, allowedHost) {
      // デフォルト設定の開発サーバーを作成する
      const config = configFunction(proxy, allowedHost);

      // この辺でカスタマイズする

      return config;
    }
  },
  // `npm test`のカスタマイズポイント
  jest: function (config) {

    // この辺でカスタマイズする

    return config;
  },
  // webpack.configのカスタマイズポイント
  webpack: function (config, env) {

    // この辺でカスタマイズする
    config = rewireSass(config, env); // <--------- ここに追加

    return config;
  },
};
```

Sass ファイルが Webpack で変換されていれば、無事 OK です。

## まとめ

react-create-app の Webpack.config をカスタマイズする方法でした。

react-create-app 便利なのですが、いままで作ったプロダクトではカスタマイズしなかったことなかったなぁ。。。
ちなみにカスタマイズは「**自己責任**」です。

カスタマイズする人は、「なぜ最近の Web フロントエンドはこんなに難しくなったのか。。。」と血の涙を流しながらやるといいでしょう。


react-create-appで作成したTypeScriptのプロジェクトのwebpack.configを上書きする


今回は、TypeScript の React プロジェクトと[react-styleguidist](https://react-styleguidist.js.org/)を一緒に使う方法についての紹介です。

紹介する内容は、こちらの Github で見ることができます。

- [mitsuruog/react\-styleguidist\-typescript\-demo: A sample for using react\-styleguidist, React and Redux\.](https://github.com/mitsuruog/react-styleguidist-typescript-demo)

## はじめに

react-styleguidist とは、「**style guide**」と呼ばれるドキュメントツールの一種です。

最近は、小さな React コンポーネントを積み重ねて巨大なアプリケーションを構築していくのですが、どんなコンポーネントがあるかを俯瞰的見るために、このようなツールを使います。

こちらで公式のサンプルを見ることができます。

- [React Styleguidist Example Basic Style Guide](https://react-styleguidist.js.org/examples/basic/)

> 個人的には、「**コンポーネントカタログ**」と言った方がバックエンドの人も理解してくれるので、こちらの呼び方をする方が多い。

## 基本セットアップ

まず、react-styleguidist をインストールします。

```sh
npm install --save-dev react-styleguidist
```

つぎに`package.json`の`scripts`の部分にタスクを追加していきます。

```json
{
  ...
  "scripts": {
    "styleguide": "styleguidist server",
    "styleguide:build": "styleguidist build"
  }
  ...
}
```

最後に`styleguide.config.js`を作成して、TypeScript のプロジェクトで動かすための設定を追加します。

```js
module.exports = {
  components: "src/shared/components/**/*.{ts,tsx}",
  webpackConfig: Object.assign({}, require("./webpack.config"), {}),
  propsParser: require("react-docgen-typescript").parse,
};
```

細かい内容はこちらです。

- `components`: コンポーネントとして扱うファイルを[glob](https://github.com/isaacs/node-glob)形式で指定します。
- `webpackConfig`: react-styleguidist は TypeScript のコンパイルができないので、Webpack の設定ファイルを指定します。
- `propsParser`: TypeScript の interface などの Props 情報をメタデータに変換するためのカスタム Paser です。

以上で、基本セットアップは完了しました。

コードのサンプルや使用例は、コンポーネントと同じディレクトリに`README.md`を作成します。

````typescript
// README.md

ここに説明```
<Lovely />
```;
````

そのあとに`npm run styleguide`をすると、スタイルガイドが見れるようになります。

## Redux と一緒に使う

Redux などのサードパーティ製のライブラリと一緒に使う場合は、既存のスタイルガイドの root コンポーネントを置き換える必要があります。
今回は割と需要がありそうな国際化ライブラリ[react\-intl\-redux](https://github.com/ratson/react-intl-redux)を使ってみました。

`Wrapper.tsx`という名前のコンポーネントを作成して、これで置き換えます。

```typescript
// src/styleguide/Wrapper.tsx

...

import { Provider } from "react-intl-redux";
import { addLocaleData } from "react-intl";
import * as jaLocale from "react-intl/locale-data/ja";

// add japanese localisation data
addLocaleData([...jaLocale]);

... (Redux storeの準備)

// デフォルトの言語設定
store.dispatch(langSwitchAction("ja"));

export default class Wrapper extends React.Component<{}, {}> {
  render() {
    return (
      <Provider store={store}>
        {this.props.children}
      </Provider>
    );
  }
}
```

Redux の Store の準備は、プロジェクトのエントリポイントのファイル(通常は`entry.tsx`とか`index.tsx`)にあると思うので、そのまま使えると思います。
いろいろ割愛しているので、詳細はこちらのコードを見てください。

- <https://github.com/mitsuruog/react-styleguidist-typescript-demo/blob/master/src/styleguide/Wrapper.tsx>

作成したコンポーネントを`styleguide.config.js`に設定します。

```diff
module.exports = {
  ...
+  styleguideComponents: {
+    Wrapper: __dirname + "/src/styleguide/Wrapper.tsx",
+  },
  ...
};
```

これでサードパーティ製のライブラリと一緒に使うことができるようになりました。

## Connect コンポーネントを使うための工夫

> この工夫は必要ない人もいると思います。ただカスタマイズが必要になった場合に必要な知識なので、頭の片隅にでも覚えておくといいと思います。

プロダクトの構成次第ですが、自分の場合はコンポーネントに関連するファイル一式を同じフォルダに管理しています。

```txt
Lovely
  Lovely.tsx
  Lovely.connect.tsx
  Lovely.scss
  Lovely.spec.tsx
  README.md
```

このような構成をとった場合、(`styleguide.config.js`の`components`の設定次第ではありますが)`Lovely.tsx`と`Lovely.connect.tsx`の 2 つがスタイルガイド上に登場してしまいます。

そのため、`components`プロパティをもう少しカスタマイズする必要が出てきます。
`components`プロパティは基本的に[node-glob](https://github.com/isaacs/node-glob)で対象となったコンポーネントのリストがあればいいので、これに関数を渡してカスタマイズします。

```js
module.exports = {
  ...
  components: () => {
    return glob.sync("src/shared/components/**/*.{ts,tsx}").filter(file => {
      // Take only connect component if exists, ignore others.
      if (file.match(/connect.tsx$/)) {
        return true
      } else {
        const pathObject = path.parse(file);
        pathObject.ext = `.connect${pathObject.ext}`
        const { root, dir, ext, name } = pathObject;
        return !fs.existsSync(path.format({ root, dir, ext, name }));
      }
    });
  },
  ...
};
```

同じフォルダに`connect.tsx`があったら、これをスタイルガイドのコンポーネントとして使うだけのコードです。
ご自身の環境に合わせてさらにカスタマイズすることもできます。

最後に`README.md`で使うコンポーネントを調整する必要があります。

README.md の Example プロックの中では、`require`でモジュールをロードして使えるので、次のように Connect コンポーネントを直接呼び出して利用します。

````typescript
// README.md

```
const FormattedMessage = require("react-intl").FormattedMessage;
const LangSwitch = require("./LangSwitch.connect").default;
<div>
  <LangSwitch />
  <p><FormattedMessage id={"greeting"} /></p>
</div>
```;
````

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/react-styleguidist01.gif)

他にもできることがあるので、詳しい説明は公式ドキュメントを見てください。

- [Documenting components — React Styleguidist](https://react-styleguidist.js.org/docs/documenting.html#writing-code-examples)

## まとめ

TypeScript の React プロジェクトと[react-styleguidist](https://react-styleguidist.js.org/)を一緒に使う方法についての紹介でした。

> (余談)
> すこし前までは、[create\-react\-app](https://github.com/facebook/create-react-app)で作成したアプリケーションは`webpack.config.js`を取り出す手段がなかったので、仕方なく eject していまいたが、今は必要ないようです。素晴らしい。
>
> - [Configuring webpack — React Styleguidist](https://react-styleguidist.js.org/docs/webpack.html#create-react-app-typescript)


TypeScriptのReactプロジェクトでreact-styleguidistを使う


新規プロダクトで「React + Redux + redux-observable + TypeScript」を使ってみました。
割と良く仕上がったので、全体アーキテクトを単純にしたサンプルを作ってまとめてみました。同じような構成を考えている人は参考にしてみてください。

対象者は、React と TypeScript(もしくは Flux)経験者です。初歩的な部分は割と割愛して説明しています。

> 続きがあるので、読み終わったらこちらも見てみてください。2019 年 1 月段階の最新です。
>
> - [typesafe\-actions を使って型安心な Redux Store を実装する \| I am mitsuruog](https://blog.mitsuruog.info/2018/12/typesafe-redux-store)

## デモ

作ったものはこちらの Github でみれます。

- [mitsuruog/react\-redux\-observable\-typescript\-sample: A sample application for React \+ redux\-observable \+ TypeScript](https://github.com/mitsuruog/react-redux-observable-typescript-sample)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/redux-observable01.png)

GoogleMap と[OpenWeatherMap](https://openweathermap.org/)の API を連動させて、マップをクリックした地点の天気を表示する単純なサンプルです。

## はじめに

まずこの構成で始めようと思った方は、最初にこれに目を通すべきです。

- [piotrwitek/react\-redux\-typescript\-guide: A comprehensive guide to static typing in "React & Redux" apps using TypeScript](https://github.com/piotrwitek/react-redux-typescript-guide)

最初はよくわからないと思います。ある程度理解すると内容がわかってくると思うので、常にそばにおいて参照してください。

ちなみに「**Redux**」とは**Flux の良くある実装パターンに名前をつけたもの**です。
Flux を経験した身として、Redux の主な特徴は次の 2 点だと感じました。

- 中央管理的な State 管理(Store)
- Store 前にある Reducer(減速機)

> **Reducer(減速機)**とは、Store の手前にあるレイアーで、Store の値を直接変更する役割をしています。
> Action から Action を呼び出して、(加速しながら？)何周かぐるぐる回ることもあるので、(安全のため？)減速機を通してから Store を変更するためこのような名前になったのではと想像しています。

Flux の説明としては下の図が有名ですね。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/redux-observable02.png)

> <https://github.com/facebook/flux/tree/master/examples/flux-concepts> より

通常は登場人物は以上なのですが、今回は Redux で副作用を処理部分に edux-observable を使っているため、もう一人「**Epic**」が登場します。

それでは順にキーポイントとなる部分を紹介していきます。

## Action と Constants

まず Action を作ります。
Action はこれから Store を変更するための起点となる部分です。基本的には`type`となんらかのデータ構造(今回は`params`と`payload`)をとります。

```typescript
// actions/index.ts
export interface Action {
  type: string;
  payload?: {};
  params?: {};
}
```

type は他の Reducer や Epic でも使うので、定数化して`Constants`の中に定義しておきます。

```typescript
// constants/index.ts
export const WEATHER_GET = "@@weather/GET";
...
```

基本的には`@@XXX/SET`を Reducer 用、それ以外(例えば`@@XXX/GET`)を Epic で使うようにしています。(そこまで厳密じゃないです。)

Action 名は重複すると見つけにくい不具合の原因になるため、[typesafe-actions](https://github.com/piotrwitek/typesafe-actions)を使って定義していきます。

```typescript
export const weatherGetAction = createAction(WEATHER_GET, (params = {}) => ({
  type: WEATHER_GET,
  params,
}));
```

## Reducer

次に Reducer を作ります。
Reducer は直前の State と Action で渡されたものを引数に、新しい State を返す役割をしています。

```txt
(previousState: State, action: Action) => newState: State
```

まず、State と初期 State を定義します。

```typescript
// reducers/WeatherReducer.ts
export interface WeatherState {
  loading: boolean;
  weather?: Weather;
}

const initialState = {
  loading: false,
};
```

次に Reducer を定義していきます。

```typescript
export const weatherReducer = (
  state: WeatherState = initialState,
  action: Action
): WeatherState => {
  switch (action.type) {
    case WEATHER_SET:
      return Object.assign({}, state, { weather: new Weather(action.payload) });

    default:
      return state;
  }
};
```

Reducer の定義の部分で初期 State(`initialState`)を設定しているのが見てわかると思います。

また、Object.assign は`Object.assign(state, newState)`としないでください。こうすると元の State を上書きしてしまうので、Redux が State の変更を検知できません。

ここで正しく State が変更されて初めて、Redux はその変更を検知して React などに対して再描画の指示を出すことができます。

## Epic

次に Epic を作ります。
Epic は redux-observable のコアコンセプトの 1 つで、**Action から呼び出されて、Action を返します。**
そのため Epic の作成は「**任意**」です。Action から何か別の Action(例、API アクセス、並列処理など)を呼び出す必要がある場合のみ利用します。

```txt
(action$: Observable<Action>, store: Store) => Observable<Action>
```

もっとも簡単な Epic 例は、Action を受け取って、別の Action を返すものです。

```typescript
const deadSimpleEpic: Epic<Action, RootState> = (action$, state) =>
  action$
    .ofType(LOVELY_TYPE)
    .map((action: Action) => nextAction(action.payload));
```

次に API アクセスする例です。

> 実際のプロダクトでは、`Rx.Observable.ajax`を使ってみたのですが、個人的に好みではなかったので`fetch`を使った例にしています。

`fetch`は Promise を返すので、これを Observable に変換する共通クラスを作成しています。

```typescript
// shared/services/Api.ts
const getWeather = (lat: number, lng: number) => {
  const request = fetch(`some_lovely_URL_will_be_here!!`).then((response) =>
    response.json()
  );
  return Observable.from(request);
};
```

これを Epic の`mergeMap`で受け取って、別の Action に繋ぎます。`weatherSetAction`は Store を更新する Action です。

```typescript
// epics/WeatherEpic.ts
const weatherGetEpic: Epic<Action, RootState> = (action$, state) =>
  action$
    .ofType(WEATHER_GET)
    .mergeMap((action: WeatherAction) =>
      getWeather(action.params.lat, action.params.lng).map((payload) =>
        weatherSetAction(payload)
      )
    );
```

最終的には、複数の Epic をまとめて 1 つにします。

```typescript
// epics/index.ts
const epics = combineEpics(...weatherEpic);
```

redux-observable の Epic を使った場合にはじめに混乱するポイントとしては、**Action から Reducer に直接繋がるケースは少なく、別の Action を経由してから Reducer に繋がる点**です。

```txt
// Epicを使わない場合
Action => Reducer => Store => Re-render

// Epicを使った場合
Action(@@XXX/GET) => API call => Action(@@XXX/SET) => Reducer => Store => Re-render
```

## Connect

次に、Connect を作ります。
Connect は React と Flux の実装パターン(たぶん、コンテナパターン)の一種で、[react-redux](https://github.com/reactjs/react-redux)が採用しているものです。

React コンポーネントを「**Connect**」というコンテナでラップして、Redux の Store との橋渡しをします。
実際には次の 2 つの橋渡しです。

- Store からコンポーネント(慣例で`mapStateToProps`とする)
- コンポーネントから Store(慣例で`mapDispatchToProps`とする)

まず、この Connect コンポーネントが外側に見せる Props(`OwnProps`)を定義して、Store との橋渡し部分を定義します。

```typescript
// components/Weather.connect.tsx
interface OwnProps {}

const mapStateToProps = (state: RootState) => ({
  weather: state.weather.weather,
});

const mapDispatchToProps = (dispatch: Function, props: OwnProps) => ({
  // 今回は実際にないけど、あったらこんな感じで書く
  someEventHander: (payload: {}) => dispatch(someLovelyAction(payload)),
});
```

connect のインターフェースは一見難しいのですが、Higher order component(HOC)だと思うとわかりやすいかと思います。
まず、Store との橋渡しの定義を設定した HOC を作成してから、オリジナルのコンポーネントを渡して、Connect でラップされたコンポーネントを取り出します。

```txt
connect(mapStateToProps, mapDispatchToProps)(OriginalComponent) => ConnectComponent
```

これで、**外側から見ると`OwnProps`のコンポーネントで、中はしっかり Redux の Store を繋がっているコンポーネント**の出来上がりです。

```typescript
// components/Weather.connect.tsx
export default connect<{}, {}, WeatherProps>(
  mapStateToProps,
  mapDispatchToProps
)(Weather) as React.ComponentClass<OwnProps>;
```

## Store

最後は Store の設定です。Store をアプリケーションで有効にして、Connect が正しく機能するようにしましょう。

上で作成した Connect を有効にするためには、これらの外側を`Provider`というコンポーネントで囲う必要があります。
Store の作成は通常の Redux と同様に`createStore`を使って行います。

```typescript
const store = createStore(reducers, preloadedState, enhancer);

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById("root")
);
```

以上で紹介終わり。

## まとめ

ちょっと詳細割愛してしまった部分もありますが、細かな部分は実際の[Github リポジトリ](https://github.com/mitsuruog/react-redux-observable-typescript-sample)を見てもらえれば雰囲気わかるかと思います。

正直「Redux + redux-observable」は学習コスト高めです。使う人を選びます。
自分は習得できたし、他の人に教えることもできると思うので次のプロダクトでも機会があれば使うと思います。しかし、他の人にはあまり気持ちよく勧められない部分もあるのも事実です。とはいえ、やりごたえはあると思うので、興味がある方はトライしてみては如何でしょうか。

その他、個人的に目を通しておいた方がいいと思うもの。

- [Redux ユーザーが最もハマる state の不正変更とその検出方法 \| I am mitsuruog](https://blog.mitsuruog.info/2018/02/why-is-immutability-required-by-redux)
- [Immutable Update Patterns \- Redux](https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns)
- [Ecosystem \- Redux](https://redux.js.org/introduction/ecosystem)


React + Redux + redux-observable + TypeScriptの実践的サンプル


今日は Redux ユーザーが最もハマるポイントだと個人的に思っている、state の不正変更とその検出方法について紹介します。
ちなみに React での話ですが、他のフレームワークでも同じ事なんではと、勝手に想像しています。

## Redux の state 変更検知の仕組み

まず最初に Redux の state 変更検知の仕組みについておさらいします。概要だけ紹介するため、詳細は公式ドキュメントも合わせて参照してください。

- Immutable Data - Redux <https://redux.js.org/faq/immutable-data>

Redux の state の変更検知には「**shallow equality checking**」という仕組みを使っています。
shallow equality とは、あるネストしたオブジェクトがあった場合、**全ての値をチェックしているのではなく、このオブジェクトが格納されている参照(マシンメモリの番地)が正しいことをチェックする**ことです。そのため「reference equality」とも言われているようです。

Redux の state は内部的に state をいくつかの部分に分割した状態で保持していますが、1 つ 1 つは比較的大きい構造となる場合が想定されるため、このように参照のみをチェックすることでパフォーマンスを担保しています。

通常 Redux の state を変更する時は、state の変更を検知できるように変更することが望ましいのですが、残念ながら検知できない変更方法が存在します。
これを便宜上「**state の不正変更**」と呼ぶ事にします。

## state を不正変更できてしまうメカニズム

これは JavaScript の言語仕様に深く関係しています。

例えば`const`は再代入を許さない変数宣言ですが、再代入のチェックに**参照を利用している**ため、オブジェクト内部のプロパティは変更することが可能です。

```javascript
const state = { name: "foo" };

// これはエラーにならない
state.name = "bar"

// これは再代入に当たるためエラーになる
const state = { name: "foo" };
```

JavaScript の場合、オブジェクト内部の**プロパティを変更したとしても参照は同じものとなる**ため、参照を使ったチェックではオブジェクトの内部の変更を検知することはできません。

## Redux の state を不正変更するとどんな問題が起きるのか？

さて、state を不正変更するとどんな問題が起こるかというと、React 上で再描画(re-render)が発生しなくなります。

これは React が持つメカニズムのためで、Props の変更を検知して、これが利用されている React コンポーネントのツリーのみを効率良く再描画させるためです。
これが起こると state は変更されているが、**画面の表示内容がまったく変化しない**というかなり面倒な事が発生します。

よくある事例として、React の component 内にある`componentWillReceiveProps`が予期せず発火しなくなります。

```javascript
componentWillReceiveProps(nextProps) {
  if (nextProps !=== this.props) {
    // なにかの処理
  }
}
```

この状態を redux-dev-tool で見ると次のようになります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/redux-01.png)

> state を変更しているはずだが、redux-dev-tool の diff には何も現れてこない。

これに起因する問題は見つけにくく、個人的には Redux ユーザーが Redux で最もハマりやすいポイントだと思います。

## state の不正変更に対する正しいアプローチ

公式に「Immutable Update Patterns」というドキュメントがあるので、これに習って state を変更します。(これくらい state の更新には細心の注意が必要です)

- Immutable Update Patterns · Redux <https://redux.js.org/docs/recipes/reducers/ImmutableUpdatePatterns.html>

Immutable Update Patterns を見るとわかるのですが、かなり面倒です。
そのため通常は、なんからのユーティリティライブラリの力を借りている方も多いかと思います。

- kolodny/immutability-helper: mutate a copy of data without changing the original source
  <https://github.com/kolodny/immutability-helper>
- debitoor/dot-prop-immutable: Immutable version of dot-prop with some extensions
  <https://github.com/debitoor/dot-prop-immutable>

しかし、上で話した通り JavaScript の言語仕様もあり、うっかり事故が絶えません。
そのため個人的には、なんからの**検知の仕組みをプロジェクトに導入するのが上策**だと考えました。

## state の不正変更を検知する

Redux の middleware に state の不正変更を検知するものがあったので、これを使います。

- leoasis/redux-immutable-state-invariant: Redux middleware that detects mutations between and outside redux dispatches. For development use only.
  <https://github.com/leoasis/redux-immutable-state-invariant>

### redux-immutable-state-invariant を導入する

導入はドキュメントにある通り、redux を初期化している部分で middleware に設定します。
ドキュメントには`redux-thunk`を使った例しかないので、`redux-observable`を使ったものにしてみます。

```javascript
const { applyMiddleware, combineReducers, createStore } = require("redux");
const createEpicMiddleware = require("redux-observable");
const epics = require("./epics/index");
const reducers = require("./reducers/index");

// Be sure to ONLY add this middleware in development!
const middleware =
  process.env.NODE_ENV !== "production"
    ? [
        require("redux-immutable-state-invariant").default(),
        createEpicMiddleware(epics),
      ]
    : [createEpicMiddleware(epics)];

// Note passing middleware as the last argument to createStore requires redux@>=3.1.0
const store = createStore(reducers, applyMiddleware(...middleware));
```

middleware を導入した状態で、state を不正変更すると次のようなエラーが発生します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/redux-02.png)

**警告ではなくエラー**なので注意が必要です。既に state を不正変更コードがある場合、最悪アプリケーションが動作しなくなります。

> これくらい清々しくクラッシュしてくれた方が、修正のモチベーションになっていいと思います。

これでうっかり state を不正変更した場合でも検知することができます。

## まとめ

今日は Redux ユーザーが最もハマるポイントだと個人的に思っている、state の不正変更とその検出方法について紹介でした。

人は間違い起こすものなので、このような検知の仕組みを導入すると安心ですね。


Reduxユーザーが最もハマるstateの不正変更とその検出方法


React の Higher order component(以下、HOC)を TypeScript で作る方法の紹介です。
作り方を探したところ、こちらの記事がほぼ完璧だと思ったので、本人に許可をもらってゆるく翻訳しながら紹介することにしました。

(完全な翻訳を目指しているわけではないので、細かいニュアンスまで気になる方は英語の記事を直接読んでください。あと少しコードは自分好みに変えてます。)

- React Higher-Order Components in TypeScript made simple
  <https://codeburst.io/react-higher-order-components-in-typescript-made-simple-6f9b55691af1>

> 本人によると、この記事は HOC の作り方について同僚とディスカッションした内容をまとめたものだそうです。同僚大事。

## HOC とは何か？

[公式ドキュメント](https://reactjs.org/docs/higher-order-components.html)によると、HOC とは

> a higher-order component is a function that takes a component and returns a new component
> (HOC とは、コンポーネントをもらって新しいコンポーネントを返す関数です。)

HOC は機能横断的な機能を抽出するために利用され、複数のコンポーネントを一箇所にまとめることで、コードの重複を減らすことができます。
ちなみに、もっとも有名な HOC は[react-redux](https://github.com/reactjs/react-redux)の`connect`だそうです。

## これから学ぶこと

この記事では、`clickCountHOC`という HOC を作成します。

`clickCountHOC`はクリック数を子コンポーネント(**wrapped コンポーネント**と呼ぶ)の props に渡します。さらにクリック数を表示して、`style` prop を使ってスタイリングすることが可能です。
そして最後に、クリックした時に`console.log`が出力できるよう、設定できるようにします。

これらの要素は、HOC の全ての側面を可能な限りシンプルに説明するために選ばれています。

## Props

まず、HOC を作成する際には**3 種類の Props**について考える必要があります。

- `OriginalProps`は、ラップされるコンポーネントが持つ**オリジナルの Props**です。HOC はこれらの内容をを全く知りません。
- `ExternalProps`は、HOC によって定義された Props です。これらはラップされるコンポーネントには渡されません。
- `InjectedProps`は、HOC が**ラップされるコンポーネントに追加する Props**です。これらは基本的に、HOC の State と`ExternalProps`を合成したものです。

これら 3 つの prop の関連は次のような図で表すことができます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/hoc1.png)

この図でわかるように、resulting component(HOC で新しく作られたコンポーネント)の Props は`OriginalProps & ExternalProps`(2 つを合成したもの)です。

今回の例の`clickCountHOC`Props はこのようになります。

```typescript
interface ExternalProps {
  style?: React.CSSProperties;
}

export interface InjectedProps {
  clickCount?: number;
}
```

`InjectedProps`は HOC を利用する際に使うため、export する必要があります(後述)。
そして State はシンプルで、ただクリックカウントがあるだけです。

```typescript
interface State {
  clickCount: number;
}
```

## Options

最初に言ったように、HOC とは、コンポーネントをもらって新しいコンポーネントを返す関数です。

(これを簡単に図示すると)

```typescript
(Component) => Component;
```

しかし、多くの HOC はオプションの設定をもらって HOC を返す、カリー化された HOC ファクトリーのような形式になっています。(`react-redux`もそう)

```typescript
(options) => (Component) => Component;
```

これらのオプションは HOC 自体を変更するために利用される静的な定義体です。
また、これらは State や Props に対するアクセスはできず、HOC ファクトリーが呼び出された時に**一度だけ評価される**ことに注意してください。

もし、この場所から Props や State を操作する必要がある場合、唯一の方法は、関数としてオプションを指定することです。引数として Props や State を受け取ることができます。

`clickCountHOC`のオプションはシンプルで、クリックした時にメッセージをコンソールに出力するかを指示するためのフラグです。

```typescript
interface Options {
  debug?: boolean;
}
```

## 全てを一箇所にまとめる

必要な全ての Props を定義し終えたら、HOC を書く事ができます。

```typescript
export const clickCountHOC =
  ({ debug = false }: Options = {}) =>
  <OriginalProps extends {}>(
    WrappedComponent: React.ComponentType<OriginalProps & InjectedProps>
  ) => {
    // body
  };
```

一目見ただけでは、少し複雑に見えるので、パーツごとに分解してみましょう。

```typescript
({ debug = false }: Options = {}) =>
```

最初の行は一つの引数をもらうラムダ関数で、ES6 の destructuring 構文を使って、デフォルト値を持つキーとして分解されています。(今回の場合、キーは`debug`)
これにより呼び出し元が、この関数を**引数なし**か**1 つの`Options`を引数**として呼び出せるようになります。そして一部のキーが渡されなかった場合、内部的にデフォルト値が利用されます。

```typescript
<OriginalProps extends {}>(
  WrappedComponent: React.ComponentType<OriginalProps & InjectedProps>
) => {
  // body
};
```

2 つめは、1 つの型引数`OriginalProps`を伴った generic ラムダ関数です。
`extends {}`は、HOC が JSX タグではなくラムダ関数であることを指し示すための、決まり文句のようなものです。

このラムダ関数は`WrappedComponent`というただ 1 つの引数をとり、2 つの型になる可能性があります。(大文字から始まることに注意してください。これは意図的で、後ろの方に理由が書いてあります。)

> (注意)原文では、`React.ComponentClass`と`React.StatelessComponent`の 2 つを使っていますが、コメントでよりシンプルなやり方として`React.ComponentType`が提示されていたので、これを使っています。

- `React.ComponentType` - `React.ComponentClass` と `React.StatelessComponent` を合成した型です。

この Props の型は上の図にある、2 つの型がラップされるコンポーネントに渡される場所に対応しています。
これで基本的な構文ができたので、あとは中身を作っていくだけです。

```typescript
export const clickCountHOC =
  ({ debug = false }: Options = {}) =>
  <OriginalProps extends {}>(
    WrappedComponent: React.ComponentType<OriginalProps & InjectedProps>
  ) => {
    type ResultProps = OriginalProps & ExternalProps;

    return class ClickCountHOC extends React.Component<ResultProps, State> {
      static displayName = `ClickCountHOC(${WrappedComponent.displayName})`;

      constructor(props: ResultProps) {
        super(props);

        this.state = {
          clickCount: 0,
        };

        this.onClick = this.onClick.bind(this);
      }

      public render(): JSX.Element {
        return (
          <div onClick={this.onClick} style={this.props.style}>
            <span>Clicked {this.state.clickCount} times</span>
            <WrappedComponent {...this.props} {...this.state} />
          </div>
        );
      }

      private onClick() {
        if (debug) {
          console.debug("clicked");
        }
        this.setState({ clickCount: this.state.clickCount + 1 });
      }
    };
  };
```

まず最初に、resulting component の props の型(上の例では`ResultProps`)を定義します。
単純に`OriginalProps & ExternalProps`とします。

次に、この Props 型を持つ resulting component のクラスを作成します。state にも適切なものを設定してください。

静的なプロパティ`displayName`を定義します。これは(ReactDev tool などで)デバックする際に、ラップされたコンポーネント名を知るために役立つものです。そして、state を初期化するシンプルなコンストラクタを定義します。

`handleClick`はクリックカウントを計算するための関数で、`debug`が有効な場合にメッセージをコンソールに出力します。

最後は、`render`関数です。`style`と Click ハンドラを持つ`div`タグです。div の中の`span`はクリックカウントを表示します。
これが`WrappedComponent`が大文字で始める理由です、そうでなければこのようにレンダリングできません。
`OriginalProps`にあったもの全てと HOC の State にある`clickCount`と一緒に渡されます。

## HOC を使う

HOC の使い方について紹介しましょう。まず`ClickArea`というコンポーネントを作成して、これを HCO でラップします。

```typescript
import { InjectedProps } from "./ClickCountHOC";

interface ClickAreaProps {}

const ClickArea = (props: ClickAreaProps & InjectedProps) => (
  <div>Click me!!</div>
);

export default ClickArea;
```

注意することは、この props の型は`ClickAreaProps`(すなわち`OriginalProps`)と`InjectedProps`の合成ということです。こうすることで、HOC とラップされたコンポーネントから props を使う事ができます。

最後にラップした 2 つのコンポーネントを作成します。(1 つはデバック機能付き)

```typescript
import ClickArea from "./ClickArea";
import { clickCountHOC } from "./ClickCountHOC";

export interface HelloProps {}

const Wrapped1 = clickCountHOC()(ClickArea);
const Wrapped2 = clickCountHOC({ debug: true })(ClickArea);

export class Hello extends React.Component<HelloProps, {}> {
  render() {
    return (
      <div>
        <h1>Here is a simple example with HOC</h1>
        <Wrapped1 style={{ padding: 10 }} />
        <Wrapped2 style={{ padding: 10, background: "gray" }} />
      </div>
    );
  }
}
```

このように好きなコンポーネントと一緒に使う事ができ、TypeScript の型チェックの恩恵も受けることができます。

以上

## まとめ

HOC を TypeScript で作る際の簡単なサンプルと説明でした。

英語の記事に方には、[HOC のテンプレート](https://gist.github.com/no23reason/3d1d34b712313260b68e58b6113246e9#file-hoc-template-ts)もあるので、ぜひチェックしてみてください。

記事の中のコードは全てこちらのリポジトリで見ることができます。

- <https://github.com/mitsuruog/react-typescript-hoc-sample>

HOC の作り方は最初難しいので、このような素晴らしい記事に出会えて本当によかったです。ありがとう！Dan

Making HOC with TypeScript is complex work at the first glance. but I am so happy to find such a great article!!
Thanks Dan. I love you!!


ReactのHigher order component(HOC)をTypeScriptで作る

この記事は[Stripe Advent Calendar 2017 \- Adventar](https://adventar.org/calendars/2339react-stripe-elements)2 日目の記事です。

自分がフロントエンドをやっている、オンラインプログラミング学習サービス[CODEPREP](https://codeprep.jp/)に、[Stripe](https://stripe.com/)決済を組み込んでみた時の話です。

> (注意)CODEPREP は**2018 年 1 月 4 日をもってプレミアム会員プランを停止した**ため、このページはもう見ることはできません。



## はじめに

CODEPREP は React で作られているので、こちらの React コンポーネントを使ってみました。

- [stripe/react\-stripe\-elements: React components for Stripe\.js and Stripe Elements](https://github.com/stripe/react-stripe-elements)

> 自分がやったのは 2017 年 07 月くらいなので、一部内容が最新ではないものがあります。ご注意ください。

仕上がりはこんな感じです。
スタイル周りのカスタマイズが結構できたので、サービスに溶け込ませるように組み込むことができました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/stripe-1.png)

## 導入方法

> 紹介するコード概念を説明するものなので、そのままでは動かないかもしれません。ご注意ください。

導入方法は`npm install --save react-stripe-elements`してから、React コンポーネントを使っていきます。

### StripeProvider でアプリケーションをラップする

まず最初に`StripeProvider`でアプリケーションのルートコンポーネントをラップします。
この時に`apiKey`にアプリケーションアクセスキーを設定してください。

```
// index.jsx
import React from 'react';
import { render } from 'react-dom';
import { StripeProvider } from 'react-stripe-elements';

import Main from './Main.jsx'

const App = () => {
  return (
    <StripeProvider apiKey="<YOUR_APP_KEY>">
      <Main />
    </StripeProvider>
  );
};

render(<App />, document.getElementById('root'));
```

## Elements で支払いフォームをラップする

次に`Elements`で支払いフォームをラップします。`Elements`は、Stripe の入力フォームをグルーピングするために利用するコンポーネントのようです。

```
// myCheckout.jsx
import React from 'react';
import { Elements } from 'react-stripe-elements';

import CheckoutForm from './CheckoutForm.jsx'

class MyCheckout extends React.Component {
  render() {
    return (
      <Elements>
        <CheckoutForm />
      </Elements>
    );
  }
}

export default MyCheckout;
```

## injectStripe で支払いフォームをラップする

さらに`injectStripe`で支払いフォームをラップします。

`injectStripe`は、Stripe の入力フォームの様々な入力イベントを処理するために利用する**Higher-Order Component(HOC)**です。

公式ドキュメントでは、`injectStripe`は`Elements`と**一緒に使えない**ことになっているので、何も考えず`Elements`と`injectStripe`を使うコンポーネントを 2 つに分けた方がいいです。

```
// checkoutForm.jsx
import React from 'react';
import { injectStripe } from 'react-stripe-elements';

class CheckoutForm extends React.Component {
  render() {
    return (
      <form>
        ここに入力フォームが入る
      </form>
    );
  }
}

export default injectStripe(CheckoutForm);
```

## カード情報入力フォームを配置する

最後にカード情報入力用のコンポーネントを配置していきます。

Stripe の React コンポーネントには、All-on-one 型の`CardElement`と、これらを別々に分割した`CardNumberElement`, `CardExpiryElement`, `CardCVCElement`があります。

自分の場合は、レイアウトを自由にしたかったので、別々に分割されたコンポーネントを利用しました。

かなりラフですが。。。入力部品を配置したらこのような感じになると思います。

```
// checkoutForm.jsx
import React from 'react';
import { injectStripe } from 'react-stripe-elements';

class CheckoutForm extends React.Component {
  render() {
    return (
      <form>
        <CardNumberElement />
        <CardExpiryElement />
        <CardCVCElement />
        <button>支払い</button>
      </form>
    );
  }
}

export default injectStripe(CheckoutForm);
```

これで導入については終わりです。次からは細かなイベントハンドリング方法やカスタマイズについて紹介します。

## 入力フォームのイベントハンドリング

入力フォームのイベントハンドリング方法について紹介します。

### フォームの入力チェック

フォームの入力チェックは Stripe の入力コンポーネントの`onChange`にハンドラを設定して処理します。

```diff
// checkoutForm.jsx

...

class CheckoutForm extends React.Component {
+  constructor(props) {
+    super(props);
+    this.handleChange = this.handleChange.bind(this);
+  }

  render() {
    return (
      <form>
-        <CardNumberElement />
+        <CardNumberElement onChange={this.handleChange}/>
        <CardExpiryElement />
        <CardCVCElement />
        <button>支払い</button>
      </form>
    );
  }

+  handleChange(data) {
+    if (!data.complete) {
+      // ERROR
+      console.log(data.error.message);
+    }
+  }
}
```

onChange ハンドラには次のような Stripe のデータオブジェクトが渡されてくるので、これを元にエラーかどうか判断します。

```
{
  brand: "amex",
  complete: false,
  empty: false,
  error: {
    code: "invalid_number",
    message: "カード番号が無効です。",
    type: "validation_error"
  },
  value: undefined
}
```

エラーかどうかは`complete`を、メッセージは`error.massage`を見ればいいと思います。

注意点としては、このオブジェクトは入力フィールド単体で送られてくるので、フォーム全体を管理するためには別途 State などを使って状態を管理する必要があるということです。
ちょっと泥臭い実装ですが、自分はそれぞれの入力フォームのハンドラを別に定義して処理しました。

## フォームの送信処理

フォームの送信処理は、フォームの`onSubmit`にハンドラを設定して処理します。

> 現在のところフォーム送信処理は`PaymentRequestButtonElement`を使った方がエレガントかもしれません。

Stripe への支払い処理には`stripe.createToken`を呼び出して、カード情報と支払い情報を Stripe 上に登録する必要があります。処理が完了すると、Stripe はトークンを発行するのでこれをバックエンドのデータベースなどに保存しておきます。

`stripe.createToken`は`injectStripe`で設定されるオブジェクトです。`injectStripe`でラップされたコンポーネントは`props`からこのオブジェクトを利用することが可能です。

```diff
// checkoutForm.jsx

...

class CheckoutForm extends React.Component {
  constructor(props) {
    super(props);
+    this.handleSubmit = this.handleSubmit.bind(this);
    this.handleChange = this.handleChange.bind(this);
  }

  render() {
    return (
-      <form>
+      <form onSubmit={this.handleSubmit}>
        <CardNumberElement onChange={this.handleChange}/>
        <CardExpiryElement />
        <CardCVCElement />
        <button>支払い</button>
      </form>
    );
  }

  handleChange(data) {
    if (!data.complete) {
      // ERROR
      console.log(data.error.message);
    }
  }

+  handleSubmit(e) {
+    // ここにバリデーション処理
+
+    this.props.stripe.createToken().then(result => {
+      if (result.error) {
+        // ERROR
+        console.log(result.error.message);
+        return;
+      }
+      // ここで取得したトークンをバックエンドに送信して完了！！
+      console.log(result.token);
+    });
+  }
}
```

## スタイルのカスタマイズ方法

Stripe のコンポーネントはスタイルをカスタマイズすることが可能です。これを行うことで、サービスに溶け込ませるように Stripe を組み込むことができます。

自分の場合は、バリデーションエラーのスタイルをカスタマイズする必要がありました。なので、この手順はほぼ必須かと思います。
最初やり方がわからなかったので Stack Overflow で聞いてみました。

- [reactjs \- How can I put border styling with react\-stripe\-elements input component? \- Stack Overflow](https://stackoverflow.com/questions/43974321/how-can-i-put-border-styling-with-react-stripe-elements-input-component)

実際に render された後のコードを見るとわかるのですが、Stripe のコンポーネントは`.StripeElement`というスタイルを持つ DOM にラップされています。

`.StripeElement`は CSS 命名規則の BEM に則ったいくつかの状態(modifier)を持つので、これらのスタイルを変更することでカスタマイズか可能です。

```
.StripeElement {
  border: 1px solid #eee;
}

.StripeElement--invalid {
  border: 1px solid red;
}

.StripeElement--focus {
  border: 1px solid blue;
}
```

こんな感じでスタイルをカスタマイズできます。

{% img https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/stripe-2.png 400 %}

> 現在は、`Elements`の`style`に CSS スタイルをセットするとスタイルが適用されるようです。便利。
>
> - <https://stripe.com/docs/stripe-js/reference#element-options>

## まとめ

自分が Stripe を導入した時の手順でした。
2017 年 7 月にやったのですが、既にいくつかやり方が古くなってるものがありますね。

アップデートが早いようなので、実際に組み込む前に公式のドキュメントを確認した方が良さそうです。

- <https://github.com/stripe/react-stripe-elements>
- <https://stripe.com/docs/stripe-js/reference>

### おまけ

導入当時は JCB に対応してなかったので、Stripe が対応してくれた時はチーム全員で大喜びしました。懐かしい記憶です。

> (Slack のログを確認したら、2017-08-22 の出来事のようですね)
> ![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/stripe-3.png)

StripeをReactで作られたサービスに組み込んでみた話

ニッチ過ぎて誰得なのか全くわからないのですが、同じようなことで苦しめられるであろう**未来の誰かのため**に、ここに手がかりを残しておきます。



> 正直このあたりのライブラリの変化が早過ぎるので、この情報がいつ風化するかわからないのだけれど。。。

## はじめに

詰まるところ[create-react-app](https://github.com/facebookincubator/create-react-app)をベースに React アプリを作っているのですが、Redux の`connect`を使っているコンポーネントをテストする際に、次のようなエラーが出ました。

これの解決方法を残しておきます。

```
Invariant Violation: You must pass a component to the function returned by connect. Instead received undefined
```

> <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

> これを読むと書いてあるんですが、redux store と一緒テストをする場合は、`<Provider>`でラップする必要があります。

今回は、redux store と切り離して純粋なコンポーネントとしてテストする場合の解決方法です。

## サンプルコード

例えば、こんなコードです。(ラフに書いたので、このままだと動かないかも)

Component.jsx

```
import React from 'react';
import { connect } from 'react-redux';

class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}

const mapStateToProps = (state) => {
  name: state.name,
};

const wrappedComponent = connect(mapStateToProps)(Component);

export default wrappedComponent;
```

Component.spec.jsx

```
import * as React from 'react';
import { shallow } from 'enzyme';
import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## 解決方法

上のやり方では、`Component.jsx`の default export が connect でラップされたコンポーネントなので、上のエラーが発生していました。

コンポーネント自体を connect なしでテストするためには、connect でラップされたものの他に、コンポーネント自体も export する必要があります。

このコンポーネントをテストで利用します。これでエラーも発生しません。

Component.jsx

```diff
- class Component extends React.Component {
+ export class Component extends React.Component {
  render() {
    return <div>{this.props.name}</div>;
  }
}
```

Component.spec.jsx

```diff
import * as React from 'react';
import { shallow } from 'enzyme';
+ import { Component } from './Component';
- import Component from './Component';

describe('Test Component', () => {
  it('何かのテスト', () => {
    ...
  });
});
```

## まとめ

まず、公式ドキュメントに目を通せ！ということでした。

- <https://github.com/reactjs/redux/blob/master/docs/recipes/WritingTests.md#connected-components>

でも、実際に一度困ってみないと、言っている意味がわからないものですねー。

react-reduxのconnectを使ったコンポーネントをテストする時にInvariant Violationが発生して困っている人のためのヒント

[react-router v4](https://github.com/ReactTraining/react-router)の小ネタ。



## やりたかったこと

> 昔は`<IndexRoute />`があったんだけどね。。。

例えば、`/users/1`という URL にアクセスがきた時に`/users/1/info`のページを表示させたい場合。

`<Redirect />`の中にこんな感じで書くと動くと思ったんですが。。。

```
<Redirect from="/users/:id" to="/users/:id/info" />
```

## 実際の挙動

実際にリダイレクトされた URL は`/users/:id/info`でした。

なんてこったい！

## 解決方法

一度`<Route />`で囲ってから`render`を使ってリダイレクトします。
こんな感じでできました。が、正直めんどくさい。

```
<Route
  path="/users/:id"
  exact={true}
  render={({ match }) => (
    <Redirect to={`/users/${match.params.id}/info`} />
  )}
/>
```

## まとめ

前のプロジェクトでは v2 系を使っていたのですが、v4 は結構変わってて割と大変ですね。（白目

> 同じようなこと考えて PR 送ってくれている人いるんですが、こりゃマージされないな。。。
>
> - <https://github.com/ReactTraining/react-router/pull/5368>

react router v4のRedirectでURLパラメータを使う

たまに見る`uncontrolled input`関連の警告についての小ネタです。
知っていると原因がすぐわかるのですが、知らないと結構デバックに時間が掛かる面倒な警告です。



まず、React の Form 関連コンポーネントの考え方には`controlled`と`uncontrolled`の 2 つがあります。

簡単に両者の違いを説明すると、値が React の state で管理されているかどうかです。

`controlled`の方は、値が React の state で管理されていて、`setState`しないと変更できません。
それに対して`uncontrolled`は、値が React の state で管理されていないので、従来の方法で値を変更できるのですが、lifecycle イベントなどの React の様々な恩恵を受けにくくなります。

## で、本題ですが。

React でフォームがある画面を開発していると、ちょくちょくお目に掛かるのが次の警告です。
特にフォーム部品を`controlled`にしているにも関わらず、**何か**のタイミングでこの警告が発生するケースがあります。

```
Warning: App is changing a controlled input of type checkbox to be uncontrolled.
Input elements should not switch from controlled to uncontrolled (or vice versa).
Decide between using a controlled or uncontrolled input element for the lifetime of the component.
More info: https://fb.me/react-controlled-components
```

内容としては、フォーム部品の状態が**何か**の原因で`controlled`から`uncontrolled`になったことを警告している内容です。

しかし、この「**何か**」が結構わからなかったりします。

## どこをチェックすればいいのか？

これは React のフォームコンポーネントに割り当てられている State の値が、`null`か`undefined`になってしまうタイミングがあるためです。

フォームコンポーネントは State の値が`null`か`undefined`になった場合、uncontrolled になります。

この警告が発生する状況は大きく 2 つです。
もしこの警告が出た場合は、これらをチェックしてみるのが解決の近道です。

### State の初期値

まず 1 つ目はフォーム部品の State の初期値に`null`か`undefined`が設定されてる場合です。

```
this.state = {
  value: undefined
};
```

もちろんプロパティ自体が宣言されていない場合も同様に`undefined`となるので注意が必要です。

```
// this.state.valueはundefined
this.state = {};
```

### setState

もう 1 つは`setState`で値が`null`か`undefined`になるケースです。

```
this.setState({
  value: undefined
});
```

オブジェクトをそのまま設定する場合など、うっかりして起きやすいと思います。

## まとめ

React のフォームコンポーネントは、割り当てられている State の値が`null`か`undefined`になると、`uncontrolled`になってしまうので注意するべしという話でした。

- react: ^@15.0.0
- サンプル: <https://codepen.io/mitsuruog/pen/VMZLVj>

Reactのuncontrolled input warningで困った時に確認するべきたった1つのこと

自分は[CODEPREP](https://codeprep.jp/)というオンラインプログラミング学習サービスをやっているのですが、今年の 2 月に React と TypeScript を使ってフロントエンドを再構築し、半年間サービスを走らせてみた結果について振り返ってみたいと思います。



## はじめに

[CODEPREP](https://codeprep.jp/)は月間で 50 万 PV 以上ある Web サービスです。

そのため、それなりの事態は発生するだろうと思い、フロントエンドにはエラー監視を導入して、ユーザーのブラウザ上で何かエラーが発生したら、直ちに Slack に通知が来て対応できるような万全の準備をしていました。

しかし、自分が担当して来た Web サービスの中では、もっともユーザーに頻繁に使われているにも関わらず、稀に見る安定稼働のサービスとなっています。

今回は、選定したフロントエンドの技術スタックのどの辺りが良かったのか、少し振り返りたいと思います。

## TypeScript の型チェックが有効だった

事前に予想していた通り、 TypeScript の型チェックはかなり有効に働いています。

基本的には、API のレスポンスを一度フロントエンドのデータモデルクラスに変換して、これをアプリケーションで利用する形を取るのですが、データモデルクラスの段階で型安全が保証されるので、ベースとなるデータモデルの品質が普通の JavaScript と比べて格段に違います。

例えば、API のデータモデルの変更に関連するリファクタであっても、何かデータ型で矛盾している点があればコンパイルエラーで事前に検知できる。当然、必要なプロパティがない、タイポしている、これらもコンパイルエラーで検知できます。

とにかく、リファクタに対する心理的・肉体的な負担が減りました。
これの何か良かったかというと、リリース後に自信を持ってコードの改善が継続的にでき、技術負債がたまりにくくなったことです。

今のところ一番目にするエラーは、オブジェクトが`null`や`undefined`でプロパティや関数を参照するときに実行時エラーになることがあることですね。（特に初期ロード時）

これは、データモデルクラスのライフサイクルを設計し直して`null`や`undefined`の状態がないようにしたあとで、TypeScript のコンパイラの`--strictNullChecks`をオンにすると軽減できるかもしれない。

> というか、、、そもそも自分の設計が悪い。

## 末端の UI コンポーネントを徹底的に Stateless にした

ここでの Stateless コンポーネントとは、Functional stateless component のことで、内部に一切状態を保持せず、ただ外部から与えられた値を元に描画することに特化したコンポーネントのことです。

ボタン・リンク・タブなどの共通的に利用できそうな UI パーツは、Stateless コンポーネントとして小分けに作成するようにしました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/react-typescript2.png)

これにより、Stateless コンポーネントはただ与えられた値を元に UI を描画するだけとなり、props で渡される値のパターンだけ注意すればいい状態となりました。

内部に state により状態遷移を持たないので、コンポーネントがシンプルで見通しがよくなり、ほとんど不具合を起こす要因が見当たらなくなりました。

> Stateless コンポーネントからの発生する(change, click などの)イベントについては、コンポーネントの props に`onChange`などのハンドラを渡すようにして、処理自体を呼び出し元に移譲しています。

これの何が良かったかというと、末端の UI コンポーネントを信頼して使うことができることです。

仮に渡す props の値が何か間違ったとしても、TypeScript の型チェック機能が有効に作用するわけで、しっかり作り込んだ Stateless コンポーネントを作りさえすれば、あとはそれに適切な props を渡せばいいという状態になりました。

## コンテナパターンを採用してフロントのアプリケーションを 3 レイヤーに分けた

3 レイヤーとは、次の 3 つです。

- コンテナ
- ページコンポーネント
- Stateless コンポーネント

大まかに「ページコンポーネント」が各画面 1 つに対応していて、「Stateless コンポーネント」は共通的に利用する小さい UI 部品のことです。そして「コンテナ」とはいくつかページコンポーネントを束ねるコンポーネントのことです。
アプリケーションで共通で利用するデータなどを保持してたり、ページへの許可されていないアクセスをブロックする門番のような役割もしています。どちらかというと**Gateway**と言った方がしっくりくるかもしれません。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/react-typescript3.png)

> 厳密にいうと世にある React のコンテナパターンのように綺麗に責務が別れていません。かなりオリジナル色が強いです。

これの何が良かったかというと、ページコンポーネントからアプリケーション全体で必要なロジックの大部分をコンテナに移譲できたことです。
コンテナ・ページコンポーネント・Stateless コンポーネントの各役割が割としっかり分離できているので、何か問題があった場合でも、容易にどの辺りが問題ありそうかあたりをつけることができます。

## アプリケーションの構造をなるべくフラットに保った

これは先の 3 レイヤーの話ともかぶるのですが、内部の状態を保ったページコンポーネントは極力ネストさせないようにしました。

これはつまり、コンテナに対してページコンポーネントは常にフラットな構造を保つということです。

> Stateless コンポーネントはネストさせても OK です。（ただしあまり深くしなければ）

内部の状態があるページコンポーネントをネストした場合、props で渡って来た値を state に格納して、これをまた子コンポーネントに渡すといったことをやることもあるかと思いますが、これは React でよくやってしまうアンチパターンだと思います。

なぜかというと、props の変更を検知するために`componentWillReceiveProps`を実装する必要があるためです。
大抵の場合、この部分の実装は難しく、複雑になりがちで、コンポーネントのメンテナンスコストを引き上げます。

これの何が良かったかというと、このようなネストを極力減らすことで、アプリケーション全体の構造をシンプルに保ち、不要なデバックコストを削減できたとです。

普段は[react-devtools](https://github.com/facebook/react-devtools)をデバックに使っているのですが、何かおかしい動きをした時にチェックする場所が固定できる。
コンポーネントでデータを受け渡しをしている間に、なぜか途中から値が変わっている、なんて悪夢はもうありません。

## まとめ

実は、他にもいろいろ工夫している点があるのですが、大きなところはこんなとこです。

リニューアル前に React と TypeScript でプロダクトを作っているけど、なかなか良さそうだという趣旨の発表をしたのですが、正直期待以上でした。

> こちらが、リニューアル前に話した内容。

> [React+TypeScript もいいぞ](https://www.slideshare.net/mitsuruogawa33/reacttype-script)

ただ結局のところ、React を使い試行錯誤の末、React の流儀に沿って正しくできたことが大きかったかと思います。
おそらく別のフレームワークを使ったとしたら、戦略レベルでは考えることは一緒であっても、戦術レベルではもう少し違うアプローチをしていたと思います。

技術は正しく使ってこそ価値がある。

ReactとTypeScriptで半年間サービスを走らせてみてよかった点を振り返って見る

アイコンなどの画像には、少し前まで CSS Sprites を使うことが多かったと思います。しかし、最近は CSS でスタイリングできるため、カスタムフォントを作成して使用することが増えてきたように感じます。

今回は、webpack と Sass を使ってカスタムフォントを使用する方法と、その際にハマりやすい`url()`での相対パス指定方法について紹介します。



## tl;dr

- Sass でのカスタムフォントの使い方
- webpack でカスタムフォントをロードする方法
- Sass での`url()`での相対パスの指定方法のハマりポイント

## はじめに

はじめに登場人物が多いので、全体のフォルダ構成を明らかにしておきます。
JavaScript のフレームワークは React を使ったのもを想定していますが、カスタムフォント周りの設定については他のフレームワークでも代用できると思います。

```
src/
  components/
    icon/
      icon.scss
      icon.jsx
      My-font.eot
      My-font.woff
      My-font.ttf
      My-font.svg
  entry.js
  style
    style.scss
 webpack.config.js
```

`entry.js`がアプリケーションのエントリーファイルです。
`style.scss`は Sass のエントリーファイルで、`icon.scss`を`@import`しています。
`entry.js`がロードされる時に、`style.scss`もロードされインポートされている Scss ファイルがコンパイルされます。

```scss
// src/style.scss
@import "../components/icon/icon.scss";
```

## Sass でのカスタムフォントの使い方

### Sass ファイルでカスタムフォントを読み込む

カスタムフォントを読み込むには`@font-face`を利用して`font-family`にフォント名を設定します。

カスタムフォントの読み込みについては、Sass ではなく CSS の範疇ですし、詳細については他に良い記事が多くあるのでここでは触れません。

```scss
// src/components/icon/icon.scss
@font-face {
  font-family: "SuperCoolMyFont";
  src: url("./My-font.eot"),
    /* IE9 Compat Modes */ url("./My-font.eot?iefix") format("embedded-opentype"),
    /* IE6-IE8 */ url("./My-font.woff") format("woff"),
    /* Pretty Modern Browsers */ url("./My-font.ttf") format("truetype"), /* Safari, Android, iOS */
      url("./My-font.svg#myfont") format("svg"); /* Legacy iOS */
}
```

### icon コンポーネントの作成

icon コンポーネントは stateless function components で作成した非常にシンプルなものです。
将来的には、アイコンの種類やサイズを prop から渡せるようにするべきだと思います。

```js
// src/components/icon/icon.jsx
exports default function Icon() => {
  return <span className="icon" />
}
```

### icon のスタイリング

icon のスタイリングについては、Bootstrap など既存の CSS フレームワークを参考にするのがいいと思います。
基本的には icon のベースとなるスタイルに`font-family`でフォントを指定した後、`content`でフォントの Unicode を設定すればいいです。

```scss
// src/components/icon/icon.scss
.icon {
  position: relative;
  display: inline-block;

  font-family: "SuperCoolMyFont";
  font-style: normal;
  font-weight: normal;
  font-size: 24px;

  line-height: 1;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;

  &:before {
    content: "\01";
  }
}
```

### フォントの Unicode の探し方(番外編)

フォントの Unicode の確認方法については、自分の場合は SVG ファイルから探すようにしています。
(正直、これがスマートな方法かどうかわかりません。)

SVG ファイルを開くと`unicode`要素があるので、そこから Unicode を抽出します。
例えば、`unicode="&#x01;"`の場合は`&#x`を`\`に変換して`\01`として使います。

```
// src/components/icon/My-font.svg
// 抜粋です
<glyph unicode="&#x01;" d="something cool shape" />
```

もっと正しい方法があったら教えて欲しいです。

## webpack でカスタムフォントをロードする方法

webpack でカスタムフォントを使うためには、[url-loader](https://github.com/webpack/url-loader)を使って各フォントファイルをロードできるようにする必要があります。

```js
// webpack.config.js
// 抜粋です
loaders: [
  {
    test: /\.svg$/,
    loader: "url?mimetype=image/svg+xml&name=[path][name].[ext]",
  },
  {
    test: /\.woff$/,
    loader: "url?mimetype=application/font-woff&name=[path][name].[ext]",
  },
  {
    test: /\.woff2$/,
    loader: "url?mimetype=application/font-woff2&name=[path][name].[ext]",
  },
  {
    test: /\.[ot]tf$/,
    loader: "url?mimetype=application/octet-stream&name=[path][name].[ext]",
  },
  {
    test: /\.eot$/,
    loader:
      "url?mimetype=application/vnd.ms-fontobject&name=[path][name].[ext]",
  },
];
```

`name`の部分は好みで変更してください。

私の場合は SVG ファイルをフォントと画像で利用することが多く、これらを別のフォルダで管理することが多いので、格納元のディレクトリ構造そのままで出力してくれる`[path][name].[ext]`を好んで利用しています。

## Sass での`url()`での相対パスの指定方法のハマりポイント

ところが、上の方法では font ファイルが参照できずエラーとなってしまいます。

```
Module not found: Error: Cannot resolve 'file' or 'directory' . /My-font.svg
```

これは現時点では、Sass のコンパイラが URL の書き換えをサポートしていないため、`css-loader`を利用する場合は Sass のエントリーファイルから相対パス指定する必要があるからです。

- [sass-loader: Problems with url(...)](https://github.com/jtangelder/sass-loader#problems-with-url)

そのため、上の`icon.scss`でのパス指定は次のようにする必要があります。

```scss
// src/components/icon/icon.scss
$font-path: "../components/icon/";
@font-face {
  font-family: "SuperCoolMyFont";
  src: url("#{$font-path}My-font.eot"),
    /* IE9 Compat Modes */ url("#{$font-path}My-font.eot?iefix") format("embedded-opentype"),
    /* IE6-IE8 */ url("#{$font-path}My-font.woff") format("woff"),
    /* Pretty Modern Browsers */ url("#{$font-path}My-font.ttf") format("truetype"),
    /* Safari, Android, iOS */ url("#{$font-path}My-font.svg#myfont") format("svg"); /* Legacy iOS */
}
```

これで、相対パスの問題は解決されてフォントを読み込むことができるました。しかし、相対パスの指定が実物のフォントと異なるので違和感が残ります。

私の場合、`$font-path`を Sass のエントリーファイルに移動することで、その違和感を解消しています。

```scss
// src/style.scss
$font-path: "../components/icon/";
@import "../components/icon/icon.scss";

// src/components/icon/icon.scss
@font-face {
  font-family: "SuperCoolMyFont";
  src: url("#{$font-path}My-font.eot"),
    /* IE9 Compat Modes */ url("#{$font-path}My-font.eot?iefix") format("embedded-opentype"),
    /* IE6-IE8 */ url("#{$font-path}My-font.woff") format("woff"),
    /* Pretty Modern Browsers */ url("#{$font-path}My-font.ttf") format("truetype"),
    /* Safari, Android, iOS */ url("#{$font-path}My-font.svg#myfont") format("svg"); /* Legacy iOS */
}
```

これなら違和感なしです。

## まとめ

webpack+Sass でカスタムフォントを使う方法でした。
Sass の相対パスまわりでハマるケースが多いのではないかと思います。

`url()`に関してはフォントだけではなく画像についても同じことが言えるので、それぞれのエコシステムの癖を把握する必要があることを痛感しました。
この辺りは、あまり最近のフロントエンド開発に慣れてない人にとっては、学習が難しい部分となりそうな予感がします。

この記事を書くにあたって、次の記事も参考にしています。

- [Working with Fonts with Webpack | Adrian Hall](https://shellmonger.com/2016/01/22/working-with-fonts-with-webpack/)
- [Using @font-face | CSS-Tricks](https://css-tricks.com/snippets/css/using-font-face/)

webpack+Sass+reactでカスタムフォントを使う

[react-intl](https://github.com/yahoo/react-intl)を使って React アプリを国際化してみたところ、結構良かったので紹介します。



## tl;dr

- react-intl を使った React アプリの国際化方法
- react-intl を component だけではなく、utility function として使う方法

## react-intl とは

[react-intl](https://github.com/yahoo/react-intl)は、React アプリの国際化を支援するための Component と幾つかの API を提供する、Yahoo 製のライブラリです。
メッセージだけではなく数値(通貨も含む)、日付など幅広く対応しています。

今回は、メッセージの部分に特化して紹介します。

## 基本的な使いかた

基本的な使い方は、次の 3 ステップです。

- 国際化する context を設定する
- 言語設定ファイルを設定する(もし必要であれば)
- react-intl が提供する Component(`FormattedMessage`)を使ってメッセージを国際化する

### 国際化する context を設定する

まず、`IntlProvider`を使って国際化するための context を設定します。
react-intl は、この指定した context 配下で動作するため、アプリケーションのエントリーポイントに近い部分で行ったほうがいいです。
私の場合は、routing を設定する部分と一緒にしています。

```js
import React from "react";
import { IntlProvider } from "react-intl";
import AppRoute from "./AppRoute";

class App extends React.Component {

  constructor(prop) {
    super(prop);
    this.state = {
      locale: "ja",
      message: // 実際のメッセージファイル
    }
  }

  render() {
    return (
      <IntlProvider
        locale={this.state.locale}
        messages={this.state.messages}
      >
        <AppRoute />
      </IntlProvider>
    );
  }

}
```

メッセージファイルについては後で説明します。

### 言語設定ファイルを設定する

複数言語対応する場合は、追加で言語設定ファイルを設定する必要があります。

```js
import { IntlProvider, addLocaleData } from "react-intl";
import ja from "react-intl/locale-data/ja";

addLocaleData([...ja]);

// もっとたくさんの言語が必要な場合
addLocaleData([...ja, ...fr, ...es]);
```

### Component を使ってメッセージを国際化する

メッセージを国際化するためには、`FormattedMessage`を使います。

```js
import { FormattedMessage } from "react-intl";

const MyComponent = () => {
  return (
    <div>
      <FormattedMessage id="happy.birthday.to.you" />
      {/* en: Happy birthday to you */}
      {/* ja: お誕生日おめでとう */}
    </div>
  );
};
```

`FormattedMessage`の`id`はメッセージファイルのキーと一致している必要があります。
`id`は`.`で区切っていますが、これは JSON の object ではなく純粋な文字列キーです。
そのため、上の`id`を指定した場合、メッセージファイルは次のようにする必要があります。

```json
{
  "happy.birthday.to.you": "Happy birthday to you"
}
```

## utility function として使う

react-intl の Component を利用した国際化機能は非常に強力なのですが、国際化の機能自体を pure な function として使いたいケースは結構あると思います。
例えば、次のように Component の props と一緒に利用するケースなどです。

```js
import ChildComponent from "./ChildComponent";

const MyComponent = () => {
  return (
    <div>
      {/* titleを国際化したい!! */}
      <ChildComponent title="" />
    </div>
  );
};
```

そんな場合は、`IntlProvider`を直接使います。

```js
import { IntlProvider } from "react-intl";

import ChildComponent from "./ChildComponent";

const intlProvider = new IntlProvider({ locale, messages }, {});
const { intl } = intlProvider.getChildContext();

const MyComponent = () => {
  return (
    <div>
      {/* titleを国際化したい!! */}
      <ChildComponent
        title={intl.formatMessage({ id: "happy.birthday.to.you" })}
      />
      {/* en: Happy birthday to you */}
      {/* ja: お誕生日おめでとう */}
    </div>
  );
};
```

> `IntlProvider`の第 2 引数は context を渡すので、特に必要なければ`{}`でよろしいかと。

最終的にはいろいろな Component で利用したいので、Singleton な Class にしておくと、後で使い勝手がいいと思います。

## まとめ

[react-intl](https://github.com/yahoo/react-intl)を使うと国際化が非常に楽です。

一工夫することで、pure な utility function としても使うことができるので、非常に利用用途が広い優秀なライブラリだと思います。

react-intlを使ってReactアプリを国際化する

最近、React ＋ Typescript しか書いてないので、久々に小ネタを投下しようかなっと。。。



## tl;dr

- JavaScript でよくやる引数の `object = object || {}` を、Typescript でコンパイルエラーを回避しながらどうやるか。

## ユースケース

例えば、React でこのような stateless function components(以下、`Book`)を作ったとします。
`Book`はインタフェースとして、`book`を受け取って`name`を表示する非常に単純な component です。

```ts
interface IBook {
  name: string;
}

interface IBookProps {
  book: IBook;
}

export defaut function Book({ book }: IBookProps) {
  return <div>{book.name}</div>
};
```

ところが、 `book`は API から取得する必要があり、`Book`を初期化されるタイミングでは`undefined`となっています。

おそらく、`book`を`undefined`のまま、`Book`に渡した場合は、次のようなエラーが発生するでしょう。

```
Uncaught TypeError: Cannot read property 'name' of undefined
```

## ES6 Default parameters を使ってみる

早速、`book = book || {}`と行きたいのですが、ES6 の[Default parameters](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Default_parameters)を使ってみます。

```ts
export defaut function Book({ book = {} }: IBookProps) {
  return <div>{book.name}</div>
};
```

しかし今度は、 `IBook`型と一致しないというコンパイルエラーが出力されます。

```
error TS2322: Type '{}' is not assignable to type 'IBook'. Property 'name' is missing in type '{}'.
```

まぁ、当然ですね。

## 正しい Default parameters の使い方

`{}`には型を設定することができるので、Default parameters を設定するときに正しく型を指定してみます。  
これで、コンパイルエラーを無事回避することができました。さらに IDE の補完も効きます。

```ts
export defaut function Book({ book = {} as IBook }: IBookProps) {
  return <div>{book.name}</div>
};
```

## まとめ

最初は、`IBook`を実装した、クラスを定義してダミーの値を設定しないと無理かと思っていましたが、型を設定することであっさり出来ました。

Typescript の intarface は定義するの少し面倒ですが、こういう場合に重宝するので、定義した方がいいですよー。

Tag: react