
2017 年も終わるので、今年どうだったかということを振り返りたいと思います。

## CODEPREP な一年

今年を一言で言い表すと

「**[CODEPREP](https://codeprep.jp/)**」

の年でした。

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

> 「CODEPREP」はプログラミングを書いて動かしながら学ぶ実践型のプログラミング学習サービスですが、残念ながら「**2018 年 3 月 26 日**」でサービスを終了してしまいます。

今年の 2/1 のリニューアルオープンから、8/1 の有料化、そして 12/4 にサービス終了のお知らせまで、まさに怒涛の一年でした。

自分は、リードフロントエンジニアとして関わっていて、ユーザーが触る部分の実装をほとんど一人でやらせてもらっていました。CODEPREP はアクセス数が多いサービスなのですが、フロントエンドはかなり安定して運用できたこともあり、個人的にはいい仕事ができて近年でももっとも充実した一年でした。

- [React と TypeScript で半年間サービスを走らせてみてよかった点を振り返って見る \| I am mitsuruog](https://blog.mitsuruog.info/2017/08/look-back-react-typescript-after-half-year)

それとは別で CODEPREP の「ブック」と呼ばれるオンライン学習コンテンツを作成にも関わっていて、主にフロントエンド関連の学習コンテンツの企画・作成などをやっていました。

今数えてみると、コンテンツで自分がメインで関わっていたものは合計で「**38 ブック**(※1)」ありました。
2/1 以降の統計情報をちょっと出すと、**合計 3 万人**くらいの人に読まれているみたいです。

- 読まれた数: (約)30,000 人
- 最後まで読んだ数: (約)17,000 人

> 2018/1/4 から無料解放するので、この数字はもう少し増えるんじゃないかと思います。

以前からエンジニア教育には興味があったので、多くの人に自分の書いたものが届いてダブルで充実した年でした。

本業のフロントエンジニア業としては CODEPREP 以外にもう一つ別のサービスも回していたことと、コンテンツライター業の二足草鞋で、とにかく忙しくも充実した日々を遅れていたので、まさに「**完全燃焼**」できた素晴らしい一年だったと思います。

(※1)自分で書いたもの、リニューアル時に古いプックを書き直したもの、自分で企画して他の人に書いてもらってレビューしたものも含む。

## 今年やった新しい試み

今年始めた新しい試みとして、「**プライベートコンサルティング**」があります。

これは、
「今のフロントエンド事情を知っているフロントエンドエンジニアを採用できないスタートアップ企業向けに
週 1 回程度フロントエンドに関連する技術課題についてコンサルティングを受けることで
自社のフロントエンドについての課題抽出・ロードマップ作成・モブプログラミングを通し
健全なフロントエンド技術スタックを手に入れ・維持できようにする」
と言ったものです。

現在のところ 1 社だけですが、やっているとかなりコストパフォーマンスが良くて、需要と供給ががっちりマッチしているコンサルティングだなと感じています。

昨今のフロントエンドは変化が早すぎるので、ざっくばらんに相談できるフロントエンドエンジニアの参謀がいるだけでも、フロントエンドエンジニアを採用できないスタートアップ企業としては頼もしいのではないかと感じています。

## で？来年はどうしよう

まず、ちょっとまったりしたい。

それから、フロントエンドで SPA を作ることに関しては割となんでもできるようになってしまったので、次の「**強み**」を見つける一年にしたいです。

現場からは以上。みなさんも良いお年を。


2017年を振り返る


## はじめに

ん！？
この Pull Request。。。。

develop ブランチ向けだと思ったら、マージ先が master ブランチじゃないかーーーー！
うぉぉぉぉーーー！！！！
うっかりマージボタン押してしまったーーーーーーー！！

あぁぁぁーーーーーー！

（完）

そんな悲しい経験をした方は多いのではないでしょうか？

はい、私はあります。

同じ間違いは二度と起こさない。そんな自分のために Chrome 拡張機能を作ってみました。

## merge-gatekeeper-for-github とは

![](https://github.com/mitsuruog/merge-gatekeeper-for-github/raw/master/assets/images/1280-800.png)

- [merge gatekeeper for github \- Chrome ウェブストア](https://chrome.google.com/webstore/detail/merge-gatekeeper-for-gith/meogknoedhhdmkgcmmgdibeeinnhfnlg)

「merge-gatekeeper-for-github」は、GitHub の「Merge pull request」ボタンのすぐ近くに、この PR が「**どこから来てどこに行くのか**」かを表示するだけのシンプルな拡張機能です。

ちなみに、こちらが拡張機能がない場合です。

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

GitHub 上にも PR の行き先について表示はあるのですが、オリジナルのスタイルに溶け込みすぎて見落としてしまいます。
それに最近追加された review やマージのためのチェック機能のおかげで、さらにマージボタンから**遠くなってさらに見落とし易くなってしまいました。**

「merge-gatekeeper-for-github」は、マージボタンのすぐ下に、**オリジナルのスタイルを崩さず、かつ目立つ**形で必要な情報を表示します。

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

> 実際に作ったのは**8 ヶ月前**ですが、もうこれがないと恐ろしくてマージボタンが押せません。

## で、そもそも。。。

で、そもそも。。。
この件に関しては、GitHub の UI が**ミスを誘発する悪い UI**だと思います。

はい。以上。

8 ヶ月使い続けているのですが、もう手放せなくなってきました。よかったら使ってみてください。

ソースコード一式は GitHub においてあります。

- <https://github.com/mitsuruog/merge-gatekeeper-for-github>


GitHubでのうっかりPRマージ事故を防ぐChrome拡張機能を作ってみた


私がフロントエンドの**障害監視**のために導入している、[Rollbar](https://rollbar.com/)というサービスの「Telemetry」という機能にかなり驚いたので紹介します。

ちなみに私はグローバルチームで働いている隠れ Rollbar エバンジェリストです。

## はじめに

私の場合、Rollbar を主にユーザーの Web ブラウザで発生したエラーを収集するために利用しています。

Rollbar は、**今まで何が起きているか全くわからなかったユーザーのブラウザで起こったエラーを知ることができる可能性がある**という点において、自分の中では導入は必須という認識になっています。
(Rollbar には**無料枠がある**ため導入しない理由が正直見当たりません。)

そのため、自分が担当しているフロントエンド案件には、障害監視のために Rollbar を導入するようにしています。

最近「**Telemetry**」という機能が使えるようになったので、実際に運用しているサービスで有効にしたのですが、軽く衝撃を受けたので紹介したいと思いました。

## Telemetry でなにができるのか？

「Telemetry(テレメトリー)」とは、wikipedia の言葉を借りると、**遠隔測定**のことで観測対象から離れた地点から様々な観測を行い、そのデータを取得することです。

> [遠隔測定法 \- Wikipedia](https://ja.wikipedia.org/wiki/%E9%81%A0%E9%9A%94%E6%B8%AC%E5%AE%9A%E6%B3%95)

今回の場合は、ユーザーのブラウザ上で様々な観測を行い、そのデータを Rollbar へ送信することです。
2017 年 12 月のところ、次のようなデータを収集できるようです。

- `DOMContentLoaded`と`load`イベント
- ユーザーの行動(`click`と`input`イベント、SPA 上での画面遷移)
- `xhr`や`fetch`のネットワークアクセスとレスポンスデータ
- `console.log`
- その他、Rollber へ任意に送信したメッセージ

下の画像は、あるエンドポイントを呼び出した際に 400 エラーが発生した時の実際の Telemetry データです。
Telemetry を見ると、直前にユーザーがどのような行動をしていたかを把握することができます。

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

ちなみに、`textarea`の場合はその入力内容が`FormValue`として取得できるようです。
(ただし`input`で入力した中身は送信されないようで、Rollbar 上では確認できませんでした。)

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

個人的な感覚では、この Telemetry とあとで紹介する「**カスタム payload データ**」を組み合わせることで、フロントエンドで発生したエラーの原因特定がかなり楽になりました。

## Telemetry の導入方法

Telemetry の導入については、[rollbar.js](https://github.com/rollbar/rollbar.js)のバージョンが「**2.0**」以上であれば自動で有効になります。もし Telemetry を収集したくない場合は、次のように`autoInstrument`を使って停止することができます。

```js
Rollbar.configure({
  ...
  // autoInstrumentはデフォルトでtrue
  autoInstrument: false,
  ...
});
```

また、このように`network`, `log`, `dom`, `navigation`, `connectivity`を使って部分的に停止することもができます。

```js
Rollbar.configure({
  ...
  autoInstrument: {
    network: true,
    log: true,
    dom: false,
    navigation: false,
    connectivity: true
  },
  ...
});
```

> [JavaScript Integration - Telemetry](https://rollbar.com/docs/notifier/rollbar.js/#telemetry)

## カスタム payload データを設定する

Rollbar には、上の`configure`をつかってエラー情報を収集する payload にユーザーが任意のデータを追加することができます。

```js
Rollbar.configure({
  payload: {
    person: {},
    context: {},
    prettyUsefulData: {},
  },
});
```

> [JavaScript Integration - Payload](https://rollbar.com/docs/notifier/rollbar.js/#payload-1)

ここで設定したデータは「Telemetry」と同じように参照できるため、例えばページが開いた時に取得したバックエンドのデータなどを含めておいて、なにかあった時に参照するような用途で使えます。

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

## まとめ

Rollbar の「Telemetry」という機能についての紹介でした。

「Telemetry」でここまでできるということは、近いうちに**このログを元に実際の環境でもう一度再生できるようになる**と思います。

エラーが発生した場合、それを再現させるまでがどうしてもコストになってしまうため、[BrowserStack](https://www.browserstack.com/)や[Sauce Labs](https://saucelabs.com/)などのオンラインテストサービスと連携して、再現テストまで自動でできるようになったら嬉しいですね。

Telemetry の詳細については、これを書いた時と比べると変更があると思うので、公式のドキュメントを参照してください。場所はこちらです。

- [Introducing JavaScript Telemetry](https://rollbar.com/blog/introducing-javascript-telemetry/)
- [Telemetry](https://rollbar.com/docs/telemetry/)


RollbarのTelemetryがヤバすぎて恋に落ちるレベル


プロジェクトの webpack のバンドルサイズを計測して見たところ、[highlight.js](https://highlightjs.org/)が結構な割合を占めていたので、サイズを小さくする方法を試してみました。

## はじめに

この辺りの記事を参考にしています。

- [Reducing bundle size of Highlight\.js with Webpack \| Brian Jacobel](https://bjacobel.com/2016/12/04/highlight-bundle-size/)
- [Reducing bundle size of Highlight\.js with Webpack 2 \| Iris Schaffer](https://irisschaffer.com/reducing-bundle-size-of-highlight.js-with-webpack2)

## import 文の書き方でサイズが小さくなる

結論からいうと、面倒でも利用する言語ファイルを`import`した方がサイズが小さくなります。

通常のやり方。

```js
// 750.01KB
import highlight from "highlight.js";
```

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

**750.01KB**。うーん。でかい。。。
なんだか全ての言語ファイルがバンドルされている気がする。。。

次は使う言語だけ`import`した場合。

```js
// 36.36KB
import highlight from "highlight.js/lib/highlight";
import css from "highlight.js/lib/languages/css";
import java from "highlight.js/lib/languages/java";
import javascript from "highlight.js/lib/languages/javascript";
import xml from "highlight.js/lib/languages/xml";

highlight.registerLanguage("javascript", javascript);
highlight.registerLanguage("css", css);
highlight.registerLanguage("java", java);
highlight.registerLanguage("xml", xml);
```

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

**36.36KB**！！
かなりスリムになりました。

## なぜサイズが小さくなったのか？

npm install した highlight.js の中身を見ると、全ての言語ファイルを呼び出していました。
そのため、`import highlight from "highlight.js`しただけの場合、自動的に全ての言語ファイルもバンドルされてしまいます。

```js
var hljs = require('./highlight');

hljs.registerLanguage('1c', require('./languages/1c'));
hljs.registerLanguage('abnf', require('./languages/abnf'));
hljs.registerLanguage('accesslog', require('./languages/accesslog'));
hljs.registerLanguage('actionscript', require('./languages/actionscript'));

...

module.exports = hljs;
```

なるほど、面倒でも一つ一つ`import`した方が良さそうですね。

## まとめ

こんな単純なことでバンドルサイズが減らせるとは。恐ろしや。。。

> サイズの測定は一度 webpack でビルドしてから[danvk/source\-map\-explorer](https://github.com/danvk/source-map-explorer)を使って測定しました。

作業していたらこんな記事を見つけました。アプローチは同じです。

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


highlight.jsを小さくバンドルする方法


この記事は[筋肉 Advent Calendar 2017 \- Adventar](https://adventar.org/calendars/2143#list-2017-12-12)20 日目の記事です。

（たまには技術系じゃないことも書いてみようかな。。。）

私はグローバルチームで働いている隠れ細マッチョです。

最近はプログラマでトレーニングしている人も増えて来ましたねー。
私は 8 月からジムに通っているのですが、4 ヶ月間ジムに通って得たものについて紹介します。

## きっかけ

ちょうど 1 年前くらいから右肩が上がらなくなりました。

もともと肩こりや腰痛がひどかったのですが、去年ちょうど 40 歳になったこともあり、当時は間違いなく「**四十肩**」というやつかなと思っていました。

いくらマッサージや接骨院などに通っても、良くなる兆しはまったくなく、とにかくリックを背負うのがしんどくて、思い返せばいつも右肩を庇って生活していた一年でした。

ところが、今年の夏休みに海に行った時の事。
4 日間連続、娘の浮き輪を引きずって海遊びをした結果、起きたことは。

「**肩こりが消えてる!!**」

肩こりをまったく感じません。右肩も上がります！
もうとにかく信じられない状態でした。

そこで確信しました、今の自分に必要なのは、**受け(マッサージ)ではなく、攻め(トレーニング)**だったんだと。

## トレーニング方法

という訳でジムに通い始めたのですが、今のところ会社帰りにジムに寄るというスタイルで続けています。
ペースは月に 3 回くらいの軽めです。
会社が加入している健保でスポーツジムの割引があったのでこれを利用しています。

トレーニングは調整系をメインに、スタジオとマシントレーニングを 2 時間くらいかけて行ってます。

- ランニング(10 分)
- ヨガ(60 分)
- マシントレーニング(60 分)
- 風呂(30 分)

最近嬉しい事といえば、10 分で 1500m を走りきることができるまでに回復したことですね。若い頃は 1.5 倍くらい速かったので、次は 8 分台を目指したいです。

## そして得たもの

まだジムに通い始めて 4 ヶ月目なのですが、これまでに得られたものを書いて行きます。
特に肩こりなどの緩和は最近になって効果が現れて来たので、辛抱強く続けて良かったと思います。

- 四十肩が気にならなくなった
- 肩こり腰痛がなくなった
- 歩くとき体が弾むように感じる
- macbook pro を毎日持ち歩いても重く感じない
- 座る姿勢がよくなった(正しい姿勢で長時間いられる)
- 鏡を見るのが楽しい
- 子供と妻が体に触ってくる

たまに困ること

- トレーニング後の電車が辛い
- トレーニング翌日の仕事が辛い
- 無性に肉が喰いたくなる

肩こりが緩和されたのは本当に奇跡に近い体験です。これからも自分のペースで続けて行きたいと思います。

## まとめ

最近始めたジム通いについて書いて見ました。
個人的には、無理せず、少しずつ変化している自分を見るのを楽しむことが長続きの秘訣かなと思います。

> 正直、来年も続いているか怪しいが。。。

最近は長生きする人が増えて、「**人生 100 年時代**」とも言われているので、健康には気をつけていきたいですね。

ちなみに、この記事は 3 年前にデブサミに一緒に出た知り合いが、最近マッチョになっていくのを Facebook の TL で見てインスパイアされて書いたものです w。

- [筋トレを始めて半年経ったので振り返ります \- ニクニクドットミー](http://blog.nikuniku.me/entry/2017/12/18/141807)
- [デブサミ 2014 で 35 歳からフロントエンジニアにキャリアチェンジして 35 歳定年説を覆した話をしてきた \| I am mitsuruog](https://blog.mitsuruog.info/2014/02/20143535.html)


4ヶ月間ジムに通って得たもの


このブログは[Hexo](https://hexo.io/)という Node 製のブログエンジンを使っています。
これまで使っていたテーマに飽きてきたので、日本語が読みやすいブログテーマを作ってみました。

> あくまで個人の感想で個人差があります。

リポジトリはこちらです。

- [mitsuruog/hexo\-theme\-simple\-japanese: Hexo blog theme\. it makes Japanese more readable and beautiful\.](https://github.com/mitsuruog/hexo-theme-simple-japanese)

ほとんど自分仕様なので、とことん不要なものを無くしてシンプルにしてみました。
使い方は、上のリポジトリの`README.md`を見てください。

ベースの CSS は[bulma](https://bulma.io/)を使っています。


日本語が読みやすいブログテーマを作ってみた

この記事は[ファシリテーター Advent Calendar 2017 \- Adventar](https://adventar.org/calendars/2310)7 日目の記事です。



## はじめに

（たまには技術系じゃないことも書いてみようかな。。。）

私はグローバルチームで働いている隠れファシリテーターです。
今日は、私がミーティングを発起する際に事前に注意しているポイントを並べていきます。

ちなみに、ここでのミーティングとはソフトウェア開発において、何らかの決定するような種類のミーティングで、アイデアを出す種類のオープンなミーティングではありません。

それでは、Here we go!

## 目次

## いいミーティングをデザインするための心得

### 事前にアジェンダと資料を共有する

この目的は、**ミーティングの時間を短くする**ことと、**参加者の目線を合わせる**ことです。

アジェンダはどんなトピックを議論するのか、資料はそこで提案される内容など事前に知ることができます。
ミーティングが始まってから資料を共有することもあるかと思いますが、この資料に目を通すだけでも時間がかかってしまいますので、この時間を節約する上でも有効です。

よくあるパターンとして時間ギリギリまで長い文字だけで書かれた資料作成して、始まってから共有するということがあります。
この場合は読んで理解するプロセスが必要で時間もかかりますし、そのプロセスを省略した場合、そもそも議論が頭に入ってこなくなったりします。

人によっては少し考えて意見を言いたい人もいますし、代替え案を提示するために準備の時間が欲しい人もいるでしょう。
事前にいろいろと共有することは、それだけでもミーティング開始時点から議題に集中して議論できる可能性が高くなるので有効だと思います。

### 時間内に収まるサイズにアジェンダを設計する

ここで「**設計**」という言葉を使いましたが、アジェンダの作成はミーティングの「場」がどうなるかを予測しながら組み立てる、まさしく「場の設計」という作業だと思います。

人は終わる見込みが到底ないものには諦めて手を抜いてしまいがちなのに対し、もう少しで終わりそうというものには、無理をしてでも終わらせようとする傾向があると思います。

私はアジェンダをこの「ギリギリ終わる」か「少し余裕がある」状態に設計するようにしています。

どうしても収まりそうにない場合は、事前にメンバーに関連する質問をチャットなどでしておいて、議論の核心でないものをそぎ落してスリムにしておきます。
この過程で、そのまま結論に至りミーティングをしないということも多々あるので非常に有効な手段だと思います。

### アジェンダにはタイムスケジュールを載せる

アジェンダを作成する際に大事なことは、**タイムスケジュールをあらかじめ決めておく**ことです。
アジェンダで議題だけ列挙しただけでは、どの議論がどのくらいの時間を使って議論されるかを予想できていません。
これでは特定の話題で話が盛り上がったときに、この先順調にミーティングが推移しているのかが判断できません。

私はタイムスケジュールをあらかじめ決めておいて、特定の話題で時間がオーバーしそうな場合、参加者に対して議論を続けるか、ひとまず結論を出して次の話題に取り掛かるか問いかけるようにしています。

### 時間を守ること

**時間通りに始まり、時間通りに終わる。**

当然のことですが、ミーティングはそれぞれの参加者の時間を奪って成立しています。
時間通りに始まり終わりましょう。

特に海外のエンジニアは「**時間＝有限な資源**」という当たり前の感覚をしっかりと持っているので、ミーティングの時間が伸びてプライベートな時間に食い込むことを本当に嫌がります。

個人的にはミーティングに**タイムキーパー**を専任で置いた方がいいと思います。

### 決まらないことを恐れない

ミーティングを時間内に納めようとした時に起こるのが、アジェンダを最後まで消化できなかった時や、議論が迷走して結論に至れなかった時です。

そんな時は無理に延長せず、「決まらない・合意できない」ことを合意しましょう。
そんな時はまた仕切り直しです。

## まとめ

個人的に気をつけていることをつらつらと書いてみました。

私の英語力はそれほど高くないので、話があまりややこしくならないように、事前準備を入念にする必要がありました。
が、あまりグローバルに限ったことではないですよね。。。はは。

個人的には最終的にミーティングをしないことが「最高のミーティングデザイン」だと思います。

グローバルチームをファシリテートして気づいた「いいミーティング」をデザインするための心得とは

この記事は[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)

December, 2017