
プライベートで CSS を教える機会があるのですが、CSS に関しては特に苦手にしている人が多く、「どうやったらそうなれますか？」という質問をよくもらいます。

そこで普段あまり考えたことがなかったので、ちょっと考えてみました。
その中で感じたことは、**自分には見えているものが、他の人には見えていない**ということでした。

いくつかキーとなる視点がありそうなので、シリーズ化してみます。

今回は「レイアウト」について。

## はじめに

今回は次のような、コメントフィード風の UI を作るケースを想定して順に説明していきます。

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

> ちなみに自分の場合、作成時間は 15 分くらいでした。
> コードはこちらで全て見ることができます。
> <https://codepen.io/mitsuruog/pen/dmZBLM?editors=1100>

CSS が苦手な人にやらせた場合、自分が期待した通りにはならないケースが多いと思います。
ブラウザはスクリーンのサイズが大きく変化するため、絶対位置でレイアウトしても崩れてしまいます。
そのような条件の中でこれらの要素を正しく配置レイアウトするためには、レイアウトを設計するための新しい「視点」が必要です。

## 正しいレイアウトには正しい HTML 構造が必要

実は、レイアウトには**CSS の知識よりも HTML 構造の設計の知識の方が重要**です。

自分がレイアウトするために大切にしている「視点」とは、**UI のデザインを見て、どのような HTML 構造をするべきかをイメージする**ことです。これをするためには、HTML のブロックレベル要素、インラインレベル要素の特性についての理解と、これらを正しく入れ子状に設計できる必要があります。

よくあるケースとして、デザインを見て HTML 構造の設計について熟考せず、すぐスタイリングしてしまうパターン。
この場合、レイアウトするために過剰に CSS を使ってしまうことが多いような気がします。これを見ると、HTML 構造を変えるだけでもっとシンプルに作れるのに、と残念に思います。

では、自分がどのように設計していくか順に見ていきましょう。

### 大枠のブロックを設計する

今回の UI をレイアウトする場合は、まず外枠のブロックと、アバター画像とコメントエリアの 2 つのブロックをイメージします。
ブロックレベル要素は横幅全体に広がる特徴があるので、最初アバター画像とコメントエリアは縦に並べておいて、後で CSS で横並びにしていきます。

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

大枠のブロックを設計する上で大事なことは、まず大きな要素を抽出して、**一度縦に並べてから後で CSS を使って横並びにするプロセス**をイメージすることです。

ちなみに、横並びのレイアウトを考える上でのコツは、**一緒の列にしたい要素をグループ化して、その外側をブロックレベル要素で囲う**ことです。
このブロックのことを「**コンテナ**」と呼び、CSS を理解する上で重要な概念です。どこかで取り上げようかと思います。

```html
<div class="comment">
  <div class="comment-left">
    <img src="画像のURL" class="comment-avatar" />
  </div>
  <div class="comment-right">テキスト</div>
</div>
```

結果はこのようになります。
![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/css-layout3.png)

### 各ブロックの中身を設計する

次に着目する部分は、コメントエリアの構造です。
コメントエリアの中の要素は、コメントエリア横幅いっぱいのブロックで良さそうなので、単純に縦に並ます。
したがって次のようにブロックを設計します。

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

```html
<div class="comment">
  <div class="comment-left">
    <img src="画像のURL" class="comment-avatar" />
  </div>
  <div class="comment-right">
    <a href="" class="comment-name"><strong>mitsuruog</strong></a>
    <p class="comment-text">テキストテキストテキスト...</p>
    <div class="comment-buttons">ここにボタン</div>
  </div>
</div>
```

結果はこのようになります。
![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/css-layout5.png)

ボタンは横並びに配置すればいいので、インライン要素を使います。

```html
<div class="comment">
  <div class="comment-left">
    <img src="画像のURL" class="comment-avatar" />
  </div>
  <div class="comment-right">
    <a href="" class="comment-name"><strong>mitsuruog</strong></a>
    <p class="comment-text">テキストテキストテキスト...</p>
    <div class="comment-buttons">
      <a class="comment-button"><i class="fa fa-pencil"></i>編集</a>
      <a class="comment-button"><i class="fa fa-trash"></i>削除</a>
    </div>
  </div>
</div>
```

結果はこのようになります。
![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/css-layout6.png)

これで基本的な HTML の構造が完成しました。

### CSS で横並びにする

正しい HTML 構造が完成したら、はじめて CSS のスタイリングに入ります。
横並びにしたいグループのコンテナ(今回は`.comment`)を Flex コンテナに指定します。

```css
.comment {
  display: flex;

  // borderとかwidthとか設定する
}
```

その後は、細かなスタイルを指定すると、最終的な結果はこのようになります。
![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2018/css-layout1.png)

レイアウトで大事なことは、まず正しい HTML 構造を意識することですが、これをプロセスに変換すると次のようになります。

- 必要な要素をまず縦に並べてみる。(配置する)
- 横並びにする要素を見つけてグループにする。(コンテナを作る)
- 横並びにするグループに対して CSS を設定する。(横並びにする)
- 細かなスタイルを追加する。(スタイリング)

## ちょっと発展系

これまでは非常に単純な例でしたので、この中に「日時」を追加する場合、追加する場所でどのように HTML 構造を設計するべきかみてみましょう。

### 既存のブロック構造が利用できるケース

次のような位置に日時を追加する場合です。

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

よく見ると右側のエリアのブロックの中に収まりそうです。

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

そのため、右側のブロックの最下層のブロックをコンテナにして、その中に 2 つのブロックを横並びに配置します。
(青の部分が新しく追加するブロック)

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

### 既存のブロック構造が利用できないケース

次は、下の位置に日時を追加する場合です。

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

日時は右側のブロックの最下層のブロックの左側を突き破っています。
この場合、既存のブロック構造を上下に分けて再設計します。

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

右側のブロック最下層のボタンと日時を合わせて新しいブロックを構築して、次のように上下にコンテナを再配置します。
(青の部分が新しく追加するブロック)

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

> 実は上の大枠を設計する時に、このような拡張を予測して最初から上下に設計することも可能でした。HTML 構造に対するアプローチの仕方は様々です。

このように変更内容によっては HTML 構造を再構成した方が、良い場合があります。

> UI の変更を依頼する側は、このあたりの事情について全く知らないので、結構軽い気持ちで変更を依頼してくることがありますね。。。

## まとめ

今回は「レイアウト」について、できる人とできない人の視点の違いについて紹介しました。
デザインを見て HTML 構造をイメージできるのは、一種の「千里眼」っぽいなと感じますが、訓練で誰でもできるようになります。

> ちなみに、自分が作っていた[CODEPREP](https://codeprep.jp/tracks/UI%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E5%AE%9F%E8%B7%B5)のコンテンツは、ほぼ最初の章が HTML 構造の設計になっています。

さて、次はなににしようかな。


CSSができる人とできない人では何が違うのか？(レイアウト編)


今回は、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の実践的サンプル


最近、割と耳にするようになってきた、Webpack の bundle.js のサイズを減らす話。自分でもやってみたので、結果を紹介します。

> 本当はもう少し減らせるかもねー

## はじめに

現在の使っているライブラリはこんな感じです。

- React
- Redux + redux-observable

ちなみに 2 つのアプリケーションがあるので、bundle は 2 つに分けてます。

最初の状態はこちらです。サードパーティのライブラリ(node_modules)のサイズが大きいことがわかります。

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

```txt
File sizes after gzip:

629.89 KB build/static/js/organization.js
595.88 KB build/static/js/applicant.js
49.28 KB build/static/css/organization.css
49.26 KB build/static/css/applicant.css
```

大きいのは、まず`highlight.js`ですね。

```txt
// ()の中はGzipしたサイズ
--------------------------------
highlight.js  750KB(190KB)
C3.js         677KB(93KB)
rx.js         686KB(32KB)
joi-browser   382KB(40KB)
```

## highlight.js のサイズを減らす

やりかたは前に書いた自分の記事を参考に。。。

- [highlight\.js を小さくバンドルする方法 \| I am mitsuruog](https://blog.mitsuruog.info/2017/12/how-bundle-size-makes-smaller)

結果:

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

```txt
File sizes after gzip:

456.75 KB build/static/js/organization.js
422.79 KB build/static/js/applicant.js
49.7 KB build/static/css/organization.css
49.69 KB build/static/css/applicant.css
```

`highlight.js`は「**750KB(90KB) => 90KB(17KB)**」になりました。

## RxJS のサイズを減らす

やりかたはこれを参考にしました。

- [RxJS を小さくバンドルする方法。import 文の書き方で容量が変わる \- Qiita](https://qiita.com/clockmaker/items/5e2207b14dac97c4ede1)

結果:

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

```txt
File sizes after gzip:

430.94 KB build/static/js/organization.js
397.02 KB build/static/js/applicant.js
49.7 KB build/static/css/organization.css
49.69 KB build/static/css/applicant.css
```

`RxJS`は「**686KB(32KB) => 164KB(9KB)**」になりました。

## lodash のサイズを減らす

`C3.js`と`joi-browser`はパッとみた感じ減らすのちょっと難しそうだと感じたので、`lodash`のサイズを減らしてみることにしました。

通常の`lodash`は ES6 のモジュール形式ではないので、ES6 モジュール形式でビルドされている[lodash-es](https://www.npmjs.com/package/lodash-es)の方を使います。

これまで import していた箇所をこのように変えていきます。

```diff
- import { isEqual } from "lodash";
+ import isEqual from "lodash-es/isEqual";
```

結果:

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

```txt
File sizes after gzip:

414.23 KB build/static/js/organization.js
380.24 KB build/static/js/applicant.js
49.69 KB build/static/css/organization.css
49.68 KB build/static/css/applicant.css
```

`lodash`は「**526KB(24KB) => 87KB(5KB)**」になりました。

## まとめ

だいたい 3 割くらい減らすことができました。

```txt
File sizes after gzip:

build/static/js/organization.js
  629.89 KB => 414.23 KB (65.7%)
build/static/js/applicant.js
  595.88 KB => 397.02 KB (66.6%)
```

Webpack 便利なのでついライブラリ追加してしまいがちですが、バンドルサイズが大きくなってないか常に気をつけたいですね。
バンドルサイズの測定は**webpack-bundle-analyzer**を使って行いました。

- [webpack-contrib/webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer)


March, 2018

CSSができる人とできない人では何が違うのか？(レイアウト編)

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

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

Webpackでビルドしたbundleファイルのサイズを減らす