Reactを2年間使ってきた所感

2018-09-29

フリーランサーになって初めて React に触れて、いつの間にか使い始めて 2 年が経ちました。

仕事・プライベートを問わず React ずくめの 2 年間でしたので、React というフレームワークに対する理解も徐々に深くなってきたところもあるのかなと。

ということで、これから React を始めようとしている方を対象に、React を使ってきて感じた諸々を書いていこうと思います。

くそ長いエントリーになる予感…。

React に触れてきた期間と、React に対する知識は比例しない

この 2 年間で、3 つの現場で React を使用してきました。

そんな中、どの現場にも、多かれ少なかれ React を使ってきた先輩がいたのですが、今思うと、どの方も React に対する知識は非常に低かったなと。

というのも、React というフレームワークは、触りを知ればそれだけである程度書けるようになってしまう、魔法のようなフレームワークといっても過言ではありません。

で、どの自称有識者の方も、本当に触りしか知らず、小手先の知識のみで偉そうに講釈してきていたんだなぁ、と、つくずく思います。

ぶっちゃけ日本で React を使用している現場は、どこも本当にレベルが低いです。

では逆になぜ、自分がここまで強気なことが書けるのか、いくつか根拠があります。

React を使うのは簡単だけど、React を使いこなすのは本当に難しい

個人的に、React というのは、「規約やルール・思想に則って使用するフレームワーク」だと思っています。

つまり逆を返せば、規約や思想を無視してしまうと、書けば書くほど泥沼にハマっていく、恐ろしいフレームワークでもあります。

で、自分が今まで所属してきた現場は、いずれも規約や思想をガン無視して書いていたなぁ、と。

じゃあその規約や思想はどこに書いてあるんだよ!と思うのが普通ですが、ドキュメントが結構散らばっているので、そこは良くないポイントだよなぁ…と思います。

ひとまず初心者の方が守るべき規約・思想は、以下のとおりです。

Redux の使用有無に関わらず、上記 3 つは最低限把握する必要があるかなと。

この 3 つを読めば、初心者の方がやりがちな以下のような過ちを回避することができます。

  • コンポーネントの継承を行う
  • 振る舞いの異なるコンポーネントを混同させる
  • Component と SFC の違いがわからないままコーディングを行う

仕事であれば、TypeScript はほぼ必須

自分も最初は『TypeScript ってめんどくせぇなぁ…』と思っていました。

が、今となっては、TypeScript はほぼ必須かと思っています。

理由としては一つで、とかく vscode の補完の強さに限ります!

特に中~大規模プロジェクトでは、少人数・大人数関わらず、vscode の補完なしでまともにコーディングができるとは思えません。

また、React × TypeScript 用のコーディング規約もありますが、こちらもとても参考になります。

Lint もまた必須

過去に Lint なしで開発を行う現場もありましたが、今思うと、なかなかめちゃくちゃやってたなぁと思います。

自分が今携わっている現場では、以下の Lint を導入しています。

これだけ入れて、ようやく多人数による開発が進めれるかなーといった感触があります。

どの Lint も、warning が 1 件でも存在していたら、commit できないように設定してあります。

が、実際には ESLint と TSLint で矛盾したルールも存在するため、ある程度は柔軟性を持って対応する必要があるかなと。

create-react-app を使用すると、TSLint しか入っていませんが、ESLint なしで React の開発を行うのは自殺行為に等しいかなと…。

Atomic Designと React・Redux の、相性の微妙さ

これだけ知識を得てパッケージを導入したとしても、一番の悩みどころが残っています。

それが components 及び containers フォルダ以下の構成です。

大量のコンポーネントを作る以上、フォルダ管理は絶対に必要ですが、React の公式ではあまり言及されていません。

そこで、デザインパターンの一つである Atomic Design を導入するケースは少なからずあると思いますが、以下の理由より、相性がひじょーに微妙です。

  • そもそも SPA 向けに考えられたデザインパターンではないので、templates と pages が意味合いからどうしても外れる
  • Atomic Design を愚直に守って開発を行うと、とにかく pages がものすごく肥大化し、複雑化する
  • Redux と特に相性が悪い、Redux の思想と相反している部分もある

とはいえ、Atomic Design 自体はとても良い考え方です。

プロジェクトごとに妥協点を設けつつ導入すると、メリットは非常に多いと思います。

storybookもこれまた必須

Atomic Design を導入すると、各コンポーネントの役割が明白になります。

そこで、storybook という、コンポーネントをコンポーネント単位で一覧表示してくれるパッケージがありまして、これが React 及び Atomic Design と非常に相性が良いです。

今まで所属してきた現場では導入されているところがなかったのが逆に驚きですが、React で開発を行う以上、必須のパッケージかと思われます。

追加したいパッケージの選定がすごく大変

React 自体には、本当に最低限の機能しか含まれていないため、パッケージはどんどん追加していく必要があります。

例えば、ルーティングすらも外部パッケージとなっていますので、ルーティングが必要な場合は、react-router-domなどのパッケージを追加しなければいけません。

で、世界中で大量に React・Javascript 向けのパッケージが日々開発されていますので、その中でどのパッケージを導入するか、毎回選定する必要があります。

Flux を一つ導入するにも、ReduxMobXGraphQLなど、選択肢が大量にあります。

とにかくメジャーパッケージを導入すればハズレはないと思いますが、推奨パッケージがまとめてあるサイトなどはありませんので、最初はとても苦労するかなと…。

逆にマイナーパッケージは、マイナーである理由があるケースも多いので、注意が必要です。

導入を行った後、ある程度開発が進んだところでパッケージの弱点に気づいたとしても、もう後戻りできない…みたいなプロジェクトもいくつかありました。

CSS-Modulesstyled-components

パッケージの選定に際し、CSS はどうするか、悩みどころかと思います。

おそらく CSS-Modules か styled-components のいずれかを選ばれる方が多いと思いますが、どちらを選んでも、開発自体はどちらも困りません。

ただ、どちらにもメリット・デメリットがありまして。

【CSS-Modules】

メリット

  • className が絶対に被らない
  • sass が使えるため、sass に慣れている人にはかなり書きやすい

デメリット

  • いちいち className と css ファイルを紐付けるのは、意外とめんどう
  • 余計な DOM を生成しなければいけないケースもたまにある
  • webpack などで少し設定が必要

【styled-components】

メリット

  • JavaScript ファイルなため、webpack などをいじる必要がない
  • 直接 props を扱えるのは楽
  • 余計な DOM を扱うケースは少なめ

デメリット

  • コンポーネント単位での親の className 以外は文字列なため、予想外の style が当たるケースもある(コンポーネント単位で BEM 記法を使用すれば問題ない)
  • sass が使えない

結構どっちもどっちなんで、適当に選んでもぶっちゃけ問題ないと思っています。

悩んだら styled-components で良いと思いますが、css や sass 信仰が強い方は、CSS-Modules かなと。

日本語のドキュメントはほとんどない

おそらく、一番のハードルかと思われます。

Angular・Vue と違い、React の公式サイトは英語のサイトしかありません。

また、Redux も英語のドキュメントばかりで、TypeScript も全て英語のドキュメントです。

加えて、React は更新が行われるたびに仕様がかなり変わりますので、個人のブログ記事などは、半年前に書かれたものであっても当てにならないケースが非常に多いです。

ただ、公式のドキュメントはわかりやすく、頻繁に更新されますので、とにかく公式最強!で進めれば大丈夫です。

React で開発を行うには

最終的に、React で開発を行うには、以下を踏まえれるかどうかだと個人的には考えています。

  • とにかくドキュメントは英語だらけ!
  • 人と違った書き方はせず、規約と規則と思想に則って、とかく愚直に書く!
  • 公式最強!メジャーパッケージ最強!
  • TypeScript は難しいけど、ある程度覚えていかないと通用しない
  • Lint でガチガチに固めて書こう
  • Atomic Design を導入しつつも、妥協点を見つけよう
  • 悪いことは言わんから、storybook は入れとこう

他にもテスト(jest・e2e)についてなど、考慮すべき点はまだまだありますが、最初はこれくらいかなと。

おそらく、性格的には「協調性があって柔軟性があって新しい知識に抵抗がなくて安定志向で、英語に抵抗がなくて我慢強い人」があってるのかなと…そんな完璧人間いねーよ!!

でも、すごく良いフレームワークだと思います、ともに React の輪を広げてくださったら、これ幸いです。

© 2018 kk-web