「React / Redux を実務で使うということは」を読んで思ったこと
React / Redux を実務で使うということは という記事が Google ニュースに掲載されていました。
React / Redux 好きとしては興味深い内容だったので、個人的な感想を書いていこうと思います。
フロントエンドの弱みは、「ググっても情報が出づらい」ことにあると思います
ぐぐっても情報は出づらいかもしれないですが、大概の必要な情報って公式サイトに書かれているイメージがあります。
上記の記事も公式サイトへのリンクが多いですね、素晴らしいです。
確かにコンポーネントパターンはわかりづらいですが、本来論ではフロントエンドエンジニアは気にしなくて良い分野かなーと。
個人的な印象ですが、React は仮想 DOM ライブラリの中でも「完璧に近い状態に作り上げて初めてパフォーマンスが出る」ものだと思っています
個人的にはそんなことないと思います。
フレームワークごとのパフォーマンスの比較で React が劣っているみたいな記事は読んだことないですし、エビデンスがほしいですね。
パフォーマンスを意識することは大切ですが、普通の開発ではそこまで意識するようなこともないかなーと思います。
React.memo() を知る
非常に簡単に使用でき、効果は絶大です やらない選択肢はないでしょう
memo は便利な機能ですが「やらない選択肢はない」というほどのものでもないかなーと、自分は使ったことがほぼなかったり。
普段は普通の書き方をして、どうしてもパフォーマンスを上げなければいけないコンポーネントでのみ使用する、くらいの立ち位置かなーと思います。
React で State を管理するのは極力やめよう
高い確率で、最初は小さいプロジェクトでもグロースしていく内に Redux が必要になるレベルの大きさになっていくからです
ケースバイケースだと思います。
api の数や画面数、エンジニアの技術力によって柔軟に対応すれば良いんじゃないかなーと思います、数ページくらいなら不要かなと個人的には。
というかそこまでグロースするようなプロジェクトが存在するのがびっくりです。
そんなに人気が出たプロダクトに関われるとか、羨ましい…。
コンポーネントとして独立しておくと、State 管理が楽で、 formik などの外部ライブラリも使いやすくなります
細かいですが react-hook-form のほうが旬かなーと。
AtomicDesign をやめよう
これについては諸説あり、プロジェクトの規模感にもよります
もしあなたのプロジェクトが数ページを管理するフロントエンドのプロジェクトになるのであれば、Redux も導入しているでしょう
その場合は Atomi ｃ Design をやめたほうが懸命です
なぜなら、AtomicDesign がワークするということは、React/Redux の設計パターンに反しているということになるからです
今回一番つっこみたかったところです。
AtomicDesign と Redux の組み合わせの強みは、むしろ「Pages 層しか Connect してはいけない」という部分にあります。
プロジェクトの規模感によって AtomicDesign を導入するか否か、Redux を導入するか否かを判断することは正しいと思います。
が、AtomicDesign と Redux を両方とも導入するのであれば「Pages 層しか Connect してはいけない」というのが大きな恩恵となります。
AtomicDesign の本質は、例えば以下が挙げられるのかなーと。
- 最小限のコンポーネント数で効率よく大規模なプロトタイピングも行うことができる
- UI / UX デザイナーとフロントエンドエンジニア間でコンポーネントの粒度について共通の意識が持てる
- 動的なデータを流し込むフローにルールを設けることができる、つまり一番上の層からバケツリレーで流し込むことのみを許容する
ただし、これは toB の一部のシステムを作っている会社に限ったことで、toC の LP などの複雑なデザインをフロントエンドで再現するという趣旨で使っている場所ではもちろん僕も全く話が違うかなと思ってます
toB という括りはよくわからないですが、ケースバイケースということですかね？
問題となるのは「Pages 層しか Connect してはいけない」というルールにあります
Redux を真面目にやると Atom の 1 ボタンを Connect するなんてザラですし、そうした方がテストが回しやすくなりメンテしやすくなるのです（後の Redux 編で詳しく解説）
その場合は意を決して、Template と Organisms の間に Connect しても良い層を 1 つ追加しましよう
Organisms を細かく分け、そちらの層で Connect していくことで Pages が巨大化することを防ぎ、幾分もマシになると思います
AtomicDesign の考え方を改良したもので進めるのであれば、それはそれで全然問題ないと思います。
大事なことは、しっかりとしたルールのもと例外を許容しないことかなーと。
仮に、改良した設計の元開発を行っている中で設計に例外が発生した場合、それは AtomicDesign を改悪した設計になっていることに他ならないと思います。
AtomicDesign と Redux の組み合わせは Pages が必然的に巨大化します、でもそれで正解だと個人的には思います。
しっかりとしたルールが整備できないのであれば、素直に Pages を肥大化させて良いと思います。
そもそも最近のトレンド的にも、Pages が肥大化し過ぎる時点でプロトタイプを見直すべきではないかなーと。
が、この方が携わっているプロジェクトには UI / UX デザイナーが存在しないような感じを受けました。
複雑なロジックを Redux に寄せることで、見通しの良いプロジェクトを作りましょう
人によるとは思いますが、個人的には複雑なロジックを Redux に寄せるのはあんまり好きじゃないです。
何を持って複雑というのかという話にはなりますが、Redux なんてグローバルな State くらいの立ち位置であるべきじゃないかなーと、これはあくまで個人的にですが。
Pages を肥大化させるのか、Redux を肥大化させるのか、それとも BFF を挟むのか、結局ケースバイケースとしか言えないのですが…。
個人的には Pages を肥大化させていって、どうしようもなさそうなら BFF を挟むようにする気がします。
配列を Store に入れない
これは知らなかったです、勉強になりました。
normalizr を使用するんですかね？型の付与が気になるところです。
近々確認してみます。
Selector をたくさん書く
コンポーネントへは 1 つずつデータを渡す
Redux 側と Pages 側の両方で Selector を噛ませているっぽい書き方ですが、結構難易度は高そうです。
結局ルール次第かなーと。
React(UI)と Redux を一緒のものとして考えるのをやめよう
これは素晴らしいと思います、完全同意。
Presenters にはロジックを入れない
UI に関する State や Callback くらいは入れて良いと思います。
Containers にはロジックを入れない
ロジックが何を意味しているのか読み取れませんでしたが、Containers はロジックを書くところかなと。
react-redux の公式サイトにも How things work (data fetching, state updates) って書いてますしね。
Fetch したデータをそのまま仕舞うのはやめよう
個々人によって考え方が変わると思いますが、自分はそのまま仕舞う派だったりします。
とはいえ api の設計によると思うので、結局ケースバイケースかなーと。
React を使い始めて 2 年半でここまで知識をつけられた筆者の方はすごいと思います。
特に Redux 周りについては自分より何倍も詳しそうです、自分ももっと勉強しないとなー。
色々と突っ込んできましたが、大事なことは AtomicDesign が良い悪い云々 Redux が良い悪い云々ではなく、きちんとしたルールのもと誰でも保守が容易なプロジェクトの構築かなーと思います。
少なくとも自分は独自ルールの構築ができないプログラマーなので、 AtomicDesign と Presentational / Container Components の考え方にべったり乗っかって開発を行います。
AtomicDesign 以外のコンポーネントパターンもずーっと調べてはいるのですが、これというものには出会えておらず…。
まだまだ精進あるのみですね。