ちょっと過言ですが...
- 複雑で凡ミスしやすい
- 長ったらしくて意味がわからない
- 同じようなことをアチコチで書いている
- あのプロジェクトでもこのプロジェクトでも同じようなことを書いてる
みたいなボイラープレートコードに対しては、だいたい分かりやすく書けるようなライブラリがあります。
- 仕事として書くなら解決するべき問題に集中するべき
- 学習者なら、さっさとスキップして上級に進むべき
という理由でライブラリを使うことと、それを見つける努力をすることをオススメします。
もちろん、ライブラリ等を導入するときは、同僚への確認や、じゅうぶんな検証が必要です。
例: clsx — React で className を動的に切り替えたい場合
ライブラリの力を借りずに、自力で条件分岐を書こうとするとこうなります。
<div
className={`card ${disabled ? "card--disabled" : ""} card--variant-${variant}`}
/>
もしスペースを忘れてしまったら、 disabled が true のときに cardcard--disabled というクラス名になってしまいます。 しかも、出し分けたい条件が増えるたびに文字列テンプレートリテラルがどんどん長くなっていきます。
特に、条件に応じて配列になにかを追加していく、というコードを JavaScript に含まれる関数型のメソッドだけで正直に書くのは難しいです。ユーティリティを用意するかライブラリに頼りたところ。
どうしましょう？ライブラリを探しましょう。 Google で検索してもいいですし、今どきは ChatGPT も役に立つかもしれません。
このような定型的で面倒くさい処理には、便利なライブラリを考える人が大抵いるものです。
ほら、 「React クラス名 動的 ライブラリ」 で探すと出てきました。 clsx というライブラリ について書かれた記事です。ドンピシャですね。
<div
className={clsx(
"card", // これは常に含まれる
`card--variant-${variant}`, // スペースを気にせずに連結できる
{ // クラス名 : それが追加される条件 (真偽値) の形式のオブジェクトが使える
"card--disabled": disabled,
},
)}
/>
ライブラリの使い方を学習しさえすれば、単純な文字列の分割と比べてかなり楽になると思います。
- スペースの入れ忘れを心配する必要がない
- クラス名 / それが追加される条件 とはっきりと意図がわかる
- 改行を自由に含めることができて、意味の区切りがわかりやすい
- prettier でフォーマットしましょう
学習コストの問題についても、 clsx のような その特定領域のデファクトスタンダード であれば、みんなが知っているので、 コストが小さくなります。
ただし、非推奨と宣言されていないか、メンテナンスが止まっていないか。上位互換（さらに洗練されている、さらにパフォーマンスが良い） がないか、など注意が必要です。
とくに、記事の日付に注目したり、ライブラリの GitHub レポジトリを直接見に行けば気づけるかもしれません。まあここは慣れの問題ですね。
今回の場合は、 classNames というライブラリも出てきますが、どうやら clsx のほうがパフォーマンスが良い...らしい？
ほかの例
| たいへんなこと | 解決法 |
|---|---|
| 実行時の型エラー | TypeScript |
| コーディング規約 | ESLint / Prettier で強制する |
| ルーティングの設定 | Next.js |
| UI コンポーネント実装 | Radix UI / Headless UI |
| UI コンポーネント実装 (定型的な見た目でよい場合) |
Mantine UI / MUI |
| fetch によるデータ取得 | SWR / TanStack Query |
| 入力フォーム | React Hook Form |
| コンポーネント単体の動作検証 | Storybook |
まとめ
主語がデカくなりますが、日本人の多くは学生時代を通して「便利な道具に頼るのは甘え」「自力で問題を解かなければならない」という考えを刷り込まれていますが...
学校はあくまで実社会で必要な「頭の筋力」を身につける場所です。能力を鍛えるためにあえて非効率ことをする場所なのです。
筋力を鍛えたいときには丸腰でモノを持ち上げますが、実生活で重すぎて上がらないものを持ち上げたいときには、ジャッキや重機を使いますよね？
私たちにとって大事なのは
- 製品を期日中に仕上げられるか
- タスクを分担しやすいか
- バグの混入の可能性を減らせるか
- 作業の精神的・肉体的負担を減らせるか
- あとで見返したときに内容を思い出せるか
- 後任者が困らないか
という現実的な問題です。
超一流ではない我々のようなエンジニアに必要なのは、 同じ問題を解決した人が残した文書や、適切なライブラリ等を見つけてくる能力 だと思います。
学習者についても同じです。大事な問題には取り組まなければいけませんが、 退屈なだけで身にならない問題はライブラリを使って楽しちゃいましょう。
「楽をせず自力で全部やれ」は全て詐欺です。
（ちょっと過言です）