Help us understand the problem. What is going on with this article?

その技術選択は正しいか? - React、SPA、Flux、Redux

はじめに

近年Web技術は様々な選択肢が存在しています。その中でユースケースに応じて適切に技術選択することがプロダクトのためにはとても大切です。

エンジニアの興味関心だけで不要な技術選択をして、開発速度やユーザ体験の低下は起きていないでしょうか?

また技術選択をするときに正しい言語化をできているでしょうか?

  • コンポーネント開発をしたいから、Reduxを採用する
  • SPAにしたいから、Reduxを採用する
  • 単一フローを採用したいから、Reduxを採用する
  • React Hooksの登場でReduxは必要なくなった

これらはすべて適切な説明ではありません。

今回は、React、SPA、Flux、Reduxをそれぞれ採用している方が、改めてその技術選択をしていることを言語化できているかの確認になればと思います。

Reactを採用するべきか?

Reactの価値は宣言的UI、コンポーネント開発にあります。
宣言的UIではないことで発生する問題を実際に感じたことがあるのでしょうか?
もしこれらの価値を自身で説明することができなければ、Reactに限らずVue.jsやAngularなどの宣言的UIフレームワークが不要かもしれません。

また単方向バインディングもReactの特徴です。
もしこれの価値を自身で説明することができなければ、ReactとVue.jsの選択を適切にできていないかもしれません。

SPAを採用するべきか?

宣言的UIでかつコンポーネント開発が必要だからといって、SPAにしなければいけないというわけではありません。
ここには明確に技術的な境界が存在します。

名前の通り「単一ページのアプリケーション」である必要があるのでしょうか?
通常のWebページのように画面遷移してはいけないのは何故でしょうか?

あなたはSPAがないことで発生する問題を実際に感じたことがあるのでしょうか?
もしこれらを自身で説明することができなければ、SPAは不要かもしれません。

Fluxを採用するべきか?

ReactやSPAを採用したからといってFluxにする必要はありません。
ここには明確に技術的な境界が存在します。

Fluxの価値は単方向フローです。
単方向バインディングと区別せずに議論されていることがあります。
単方向バインディングと単方向フローの違いを説明できるでしょうか?

またFluxはどのように単方向フローを実現しているのでしょうか?
また単方向フローはどのような課題を解決しているのでしょうか?
単方向フローにしないとどのような実装になり、どのような問題が起きるのでしょうか?

あなたはFluxがないことで発生する問題を実際に感じたことがあるのでしょうか?
もしこれらを自身で説明することができなければ、Fluxは不要かもしれません。

Reduxを採用するべきか?

Fluxを採用したからといってReduxにする必要はありません。
ここには明確に技術的な境界が存在します。

Fluxで実現できておらずReduxで実現していることはなんでしょうか?
Reduxの三原則は、Single source of truth、State is read-only、Changes are made with pure functionsにあります。
これらの三原則がもたらすメリットはなんでしょうか?

またReduxはFluxで解決できていないProp Drillingの問題をConnect(Selector)で解決しています。

あなたはReduxがないことで発生する問題を実際に感じたことがあるのでしょうか?
もしこれらの価値を自身で説明することができなければ、Reduxは不要かもしれません。

React Hooksの登場でReduxは不要になるのか?

React Hooksの登場により、Reduxの三原則の価値はなくなるのでしょうか?
それともReact HooksのuseReducer、useState、useContextなどを利用して、Redux相当のものを自作できるということでしょうか?

もしこれらを自身で説明することができなければ、Reduxは必要かもしれません。

まとめ

Fluxを提案したReact Coreチームに所属しているDan Abramovは以下のように主張しています。

もしFluxが解決する問題をあなた自身が解決しようとしたことがない場合、Fluxが何を解決するかを理解することは難しいです。
私は人々がトレードオフを理解しないがために、Fluxの最悪な特徴を獲得して、最高の特徴を見逃すのを見てきました。
https://medium.com/swlh/the-case-for-flux-379b7d1982c6

またDan AbramovはRedux作者でもあり、別の記事では以下のように主張しています。

人々はReduxを必要とする前からReduxを使おうとします。
しかしながら、あなたが今まさにReactを学習中なのであれば、Reduxを最初の選択にしてはいけません。
その代わりReactで考えることを学びましょう。本当に必要になったら、または何か新しいことに挑戦したくなったらReduxに戻って来てください。
https://mae.chab.in/archives/2937

課題を解決するためにフレームワーク使うことが大切です。フレームワークの必要性を言語化できていない状態で採用してもフレームワークが解決している目的を達成できない可能性があります。そうなるとただ冗長なコードが増えただけという結果になりかねません。

そうならないためにも一度はフレームワークを使わずに挑戦して、フレームワークが解決しようとした課題を自分で体験することがとても大切です。

また新しく登場して流行しているフレームワークは素晴らしく見えます。
そこで新しいフレームワークを導入する際には、一度立ち止まりこのフレームワークの価値を表面的にではなく何回も深堀りして考えてみてください。

それを踏まえてプロダクトと組織のことを考え、長期的に負債を生まないように適切な解決手段を提案しなければなりません。

これらのバランスを考え技術選定できることがアーキテクトの実力の見せ所であり、本当のスキルではないでしょうか。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした