kk-web

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

2019-10-12

ふと過去のブログを漁っていると、去年こんなエントリを書いてました。

読み返してみたところ、鋭いことを書いている部分もあり、間違ったことを書いている部分もあり、でもまぁ、2 年触ったくらいならこんなもんだよなーと。

未だにわからないことづくめの毎日ですが、React を使って 3 年たった現時点での所感を書いて行こうと思います。


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

以前書いている通りだと思います、相変わらず日本の React 有識者は絶滅危惧種です。

特になんちゃってフルスタックエンジニアは本当にひどいです、まじでクソみたいなのしか会ったことないです。

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

これも特に変わらず、ただ、今からスクラッチで開発を行うのであれば、hooks オンリーでも良いかもですね。

class 構文は絶滅してほしいんですが、流石に無理そう…。

個人的には、presentational component と container component の違いがわかっているかわかっていないかで、見る目が少し変わります。

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

これも変わらず、flow は死んで良し。

Lint もまた必須

これまた変わらず、ただ、導入している linter は変わりました。

  • eslint
  • stylelint
  • commitlint

tslint は deprecated したので不要です、未だに導入してるとこは少ないとは思いますが。

ただ、eslint については、正直混乱の状態が続いてるよなーと。

世界中の誰一人として正しい導入方法を知らないんじゃないかと思ってます、厳しくしようとすればするほど設定が複雑になりすぎます。

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

変わらず微妙な認識です、導入して損はないと思いますが。

未だに Atomic Design 一辺倒な自分もどうかと思うんですが、これ以外にデザインシステムを知らないんですよね…。

storybook もこれまた必須

必須です、入ってないプロジェクトはすぐに入れましょう。

きちんと presentational component と container component で分けていれば、導入もスムーズです。

逆に、ここがわかっていないと、storybook も jest も導入が厳しいと考えています。

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

redux も mobx も graphql も flux じゃないんですってね、最近ようやく理解できてきました。

業務アプリであれば、基本的に redux か graphql で良いと思っている派です、mobx はとにかく破綻しやすい…。

まともなメンバーがそろっていれば問題ないんでしょうけど、なかなかそういう現場には出会ったことがありません。

CSS Modules と styled components

前のエントリは、ここの記述がいまいちですね。

React に CSS Modules を導入するのであれば、今はbabel-plugin-react-css-modules一択です、素のやつはおすすめできないです。

一応メリット・デメリットを改めて書くと。

babel-plugin-react-css-modules

メリット

  • js と css でファイル単位で分けられるため、ロジックの混同が発生しない
  • (styleName が使えるため、そもそも className を意識しない)

デメリット

  • 拡張子(.css など)周りについて、webpack などで少し設定が必要

styled-components

メリット

  • webpack で設定が不要
  • 直接 props を扱えるのは楽(これはかなり大きい)

デメリット

  • ファイルが大量に生成される(これが痛い)
  • (予想外のスタイルがあたるうんぬんは、当時の誤った認識です)

とはいえ、相変わらずどっちもどっちです、お好みでどうぞ。

日本語のドキュメントが増えてきた

React の公式サイトもじょじょに日本語対応が行われてきていて、とても良いことだと思います。

公式サイト以外は基本的に見なくて良いとは思うんですが、hooks 周りのドキュメントは、ある程度書ける人向けに書かれているので、そこは注意が必要です。

SSR とかいらんでしょ

初速の速さに惹かれて ssr を導入している現場が結構あるのですが。

個人的には、やっぱりどう考えてもいらないよなー…と。

とにかくメリットに比べてデメリットが多すぎる!特に開発工数の多さは痛すぎる!

ネット上でちょっと調べても、ssr 不要論を唱えてる人の方が多そうに見えるんですが、なーんでどこも安易に導入しちゃうんですかね。

ssr 自体が悪いとは思わないんですが、よほど初速がほしいケース以外では不要だと考えてます。

加えて、日本のフロントエンドエンジニアの知識が追いついていないので、ぐっちゃぐちゃなプロジェクトになることは間違いないです。

csr でちゃんと書けるようになってから、ssr に挑戦するのが正しい順序なんじゃないかなぁと…みんな ssr なめ過ぎです。

Vue と React どっちがおすすめなの

React です、仕事で使うのであれば、特に React です、Vue は日本人にあってないです。

特に Vuex 周りは、Redux と比べて自由度が高いので、メンバーが揃っていないと、まじですぐに破綻します。

あと、TypeScript 周りがまだまだです、特にここ 1 年でかなり混乱しているようで、おすすめできないです。

本当に小規模なプロジェクトだったり、趣味の範囲だったり、静的に近いサイトであればまだ許せます。

ライフサイクル周りも結構複雑な印象です、hooks ならすらすら書けるのになーと思うことが何度もありました。

たまーに、React わかんないから Vue を始めたみたいな人がいますが、React も Vue も根本はなんも変わらないので、本当にそれで良いのかなぁ…と。

React で開発を行うには

  • 規約と規則と思想に則って、没個性的に書きましょう
  • 人気のあるパッケージだけ使いましょう
  • TypeScript を使いましょう
  • lint は導入しましょう
  • prettier が入っていないプロジェクトはゴミです
  • presentational component と container component の違いを理解しましょう
  • storybook を導入しましょう
  • ssr は csr が書けるようになってから選択肢に入れましょう

相変わらずテスト周りはよわよわなので、ここでは触れません、他の人のエントリを見てね!


そんな感じです、書き疲れた。

JS 周りも React 周りも、日々色々と変化があって飽きないですね、知らない知識が多すぎて、追うのに疲れますね。

30 台に突入したので、デザイナーとバックエンドとの連携についても知識を増やしていかないとなーと思っている今日このごろです。

とりあえず、スキーマファーストと Atomic Design の認識で合わせれれば、ある程度横の連携はうまくいくんじゃないのかなー。

© 2018 kk-web