kk-web

Reactの手がかり パッケージ編

2019-10-04

React を触って 4 年になる自分ですが、環境を構築する際や、開発中に意識していることを、何回かにわけて書いていこうと思います。

今回はパッケージ編ということで、よく使うパッケージを書いていっちゃいます。

導入が前提となるパッケージ(react や react-dom など)は除いてます。

axios

HttpRequest をやってくれるやつです。

fetch と大差ないですが、エラーハンドリングの面で axios の方が好きです。

babel-plugin-react-css-modules

react でスタイリングとなると、結構どこも苦戦している印象です。

たまーにカプセル化も行わず、昔ながらの方法で静的な css ファイルのみを置いている現場とかありますが、馬鹿なの？アホなの？昭和なの？

一番メジャーなのは、やっぱりstyled-componentsなのかなと。

css を使わず全て JavaScript で完結するので、余計な設定も追加しなくて良いし、props も扱えるし、確かに便利です。

とはいえ、css-modules の上位互換かと言われると、そんな感じでもないです。

とくに、styled-components を使用すると、大量にファイルを作らないといけないのが、個人的にはちょっとイマイチでした。

あと、以前は TypeScript と組み合わせるとちょっとバグがあったんですが、今はどうなんでしょう。

styled-components の一番わかりやすいサンプルは、react-boilerplateかなーと。

material-uiとかもたまに目にしますが、ちゃんと使いこなせてる現場ってどれくらいあるんですかね。

で、babel-plugin-react-css-modules とかいう長ったらしい名前のやつは、css-modules を react 向けにした react-css-modules の完全上位互換パッケージです、ややこしい！

もともと css 好きの自分としては、以下の点でこのパッケージをおすすめしてます。

  • 1 コンポーネント 1css ファイルという、シンプルなファイル構造にできる！(個人的に一番大事)
  • Sass が使える！
  • styleName という独自の属性を使用するため、className が汚染されない！
  • babel-plugin-react-css-modules-autocompleteという vscode のプラグインを導入すると、補完も効く！しかも開発者は日本人！神！！
  • ちょっと古そうだけど、型もあります！

正直、styled-components を使いこなせている現場にあったことがないので、個人的にはこっちのほうがオススメです。

camelcase

レスポンスデータにスネークケースが使用されているのはよくあることだと思うんですが。

それをそのままオブジェクトに突っ込むのは愚の骨頂です、ちゃんとキャメルケースに変換してあげましょう。

ただ、このパッケージ、型が甘いので、使用には結構苦戦します。

似たようなパッケージも他に多数存在するので、そっちに乗り換えようかとも考え中です。

commitlint

コミットメッセージの粒度が、各々でバラバラなのが嫌いです。

なので、commitlint で見た目だけでも綺麗にしてます。

angularのリポジトリとか綺麗です、ただ commitlint は導入されてないっぽい…？

debounce

画面のリサイズに対してイベントを挟んだ場合、リサイズ時に大量に実行されちゃいます。

実行頻度を落としたい場合によく使われるのが、lodash.debounceだったりすると思うのですが。

lodash の導入って面倒なんですよね…型もよくわかんないし…はっきり言って嫌いです。

ということで lodash じゃない debounce をよく使います、便利。

eslint

説明不要、JavaScript の linter ですね。

ちょっと前に、TypeScript も正式に対応されたので、tslint は不要です。

たまに現場で、JavaScript の FW を導入しているくせに、eslint が入ってないところがあってビビります、ホラーかよ。

ただ一方で、eslint 用のパッケージは何を導入して良いのか、未だによくわかっていません。

create-react-app デフォルトのやつは、初心者向けということもあってか、結構緩めらしいです。

自分はつよつよ設定にしたい派なのですが、何を設定すりゃ良いんだか…いろんな記事を見ても、みんな書いてることバラバラだし…。

今のところ、これがベストかなーと思ってるやつを一応書いときます。

とはいえ、多分すぐに変えちゃうので、本当に参考程度で…。

"scripts": {
  "lint": "eslint --fix --max-warnings 0 --ext .ts,.tsx src/",
  "lint:watch": "esw --color --watch --fix --max-warnings 0 --ext .ts,.tsx src/"
},
"dependencies": {
  "eslint": "6.5.1",
  "eslint-config-airbnb": "18.0.1",
  "eslint-config-prettier": "6.3.0",
  "eslint-plugin-import": "2.18.2",
  "eslint-plugin-jsx-a11y": "6.2.3",
  "eslint-plugin-prettier": "3.1.1",
  "eslint-plugin-react": "7.15.1",
  "eslint-plugin-react-hooks": "2.1.1",
  "eslint-watch": "6.0.1"
},
"eslintConfig": {
  "extends": [
    "airbnb",
    "airbnb/hooks",
    "eslint:all",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
    "prettier",
    "prettier/@typescript-eslint"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint",
    "prettier"
  ],
  "rules": {
    "prettier/prettier": "error",
    "react/jsx-filename-extension": [
      1,
      {
        "extensions": [
          ".tsx"
        ]
      }
    ],
    "react/prop-types": "off"
  },
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [
          ".js",
          ".jsx",
          ".ts",
          ".tsx"
        ],
        "paths": [
          "./"
        ]
      }
    },
    "react": {
      "version": "detect"
    }
  }
}

あと、eslint の監視のために eslint-watch もよく入れます。

formik

フォームを扱う際は、よく formik を使用しています。

redux-form と同じくらいの知名度になってきたのかな？といった印象ですが、触り心地は両者大差ないです。

あと、redux-form は公式サイトがダサいのがいやです。

moment

時間とかを扱う場合はこれ一択だと思ってます。

正直 JavaScript の Date を素で扱うのは危険すぎます、複雑すぎる。

ただ、moment をそのまま使っちゃうと、ビルドファイルに全言語データが入っちゃうので、めっちゃ重くなっちゃいます。

とはいえ、create-react-app だと、余計なロケールファイルはバンドルしないよう webpack のデフォルトで設定してあるので、気にしなくて良いです。

prettier

説明不要、コードフォーマッタです。

これが入ってない現場も少なくないです、未だに手動でフォーマットとか、レビューでフォーマットを指摘するとか、ホントやめましょう、いつまでも前に進めません。

ただ、eslint との兼ね合いについては、未だによくわかっていません。

eslint 側の fix と prettier の結果が同じになればオッケー、みたいな感じなんですかね…誰か教えてー。

vscode で prettier を入れちゃうと、ついつい導入をし忘れちゃうことも結構ありますが、チームで開発を行うときは導入必須なのかなと。

react-helmet

SPA だと html ファイルが 1 つしかないため、そのままでは全てのパスに対して同じドキュメントヘッダが付与されます。

react-helmet を導入すると、ドキュメントヘッダを細かく設定することができるようになります。

react-router-dom

SPA でルーティングを行う際に、必須のパッケージです。

react-router はコアパッケージなので別モノです、ややこしい。

redux を噛ませたい場合は、connected-react-routerも入れます。

が、こちらはさほど使用しない印象です、便利なのは間違いないですが。

react-select

react でセレクトボックスといえばこれ！なくらいいい感じのパッケージです。

ただ、ちょっと機能過多なのと、スタイリングが独特なのと、formik などと組み合わせるのがちょっと難しいパッケージです。

良いパッケージなのは間違いないです。

redux

説明不要、状態管理パッケージです。

他のメジャーどこでいうと、GraphQLやmobxとかもあります。

GraphQL については、自分も多少触ってみましたが、確かにすげー便利そうだし redux の上位互換な感じも受けたんですが…。

もう少し深く触ってみないとなんとも言えないです、申し訳ないです。

あと、有識者が極端に少ないせいか、日本では全然導入が進んでいません。

脳死で rest とかも、いい加減やめてほしいです。

mobx については、正直ほぼすべての面で redux のほうが勝っていると思います。

小さいサービスならducksとかでいけると思うし。

redux を使ったことがないのに、mobx のほうが良いとか言ってくる人は、だいたいあてにならない印象です。

ress

いわゆる css リセットの一つです、ちょっとマイナーですが。

メジャーどこだと、reset.css や normalize.css、sanitize.css などがあるみたいですが。

個人的に、css のリセットは最低限のほうがありがたいので、ress を使用しています。

stylelint

eslint で JavaScript は対応できますが、css 側に linter を入れていない現場はかなり多いです。

stylelint を入れれば、css もきちんと対応されます、必須ですね。

このパッケージのすごいところは、styled-components にも対応しているところです、これはありがたい。

ルールもかなり厳し目です、デフォルトの設定に対応するのはかなり骨が折れます…。

sweetalert

ポップアップを作るのって、普通は ReactDOM.createPortal でやると思うんですが。

毎回毎回作るのが面倒なので、自分は大体 sweetalert で済ませちゃいます。

無印と 2 がありますが、個人的には無印版のほうが使いやすい印象です。

このポップアップ、おしゃれで良いですよね。

typescript

ブログ中でもたまに触れますが、TypeScript はどんなプロジェクトであっても導入しています。

TypeScript を使用していて、一番良いなーと思うところは、やっぱり vscode で補完が効くところなのかなと。

上記の他に、react-table とか react-lazyload、react-dnd あたりも便利ですが、ちょっと難易度が上がるので割愛しました。

あと、テスト関連は情弱なので書いてません、jest と nightwatch しかわからんです。

と、ぱっと思いつく範囲のものを書き出してみました。

もちろん賛否両論あるところだと思いますので、本当に参考程度に留めていただければと。

ただ、自分が本当に React を初めて触ったとき、ルーティングすらやり方がわからなかったなぁと思い出しまして。

特に React 初心者の方の参考になれば幸いです。

© 2018 kk-web