今回は、エンジニア向け読み物サービス「Mybridge」のMybridge AIがランク付けした2016年9月のReactに関する記事の1位だった記事を翻訳して紹介します。Reduxの作者Dan Abramov氏の記事です。内容は、簡単に言うと、「無理してReduxを使わなくてもいいよ」という話です。ただ、使わなくてもいい理由をReduxの特徴を挙げながら述べてくれているので、Reduxについての理解も深まる内容になっています。原文がだいぶフランクな感じで書かれているので、日本語に訳すのが少々難しく、わかりにくい部分もあるかと思いますが、是非読んでみてください。
当記事は、You Might Not Need Redux – Medium (Sep 20, 2016) by Dan Abramovを日本語に翻訳したものです。
人々はReduxを必要とする前からReduxを使おうとします。「もし我々のアプリケーションがReduxがないことでスケールできなかったらどうするの?」。後ほど、開発者たちはしかめっ面をして自分たちのコードに導入された間接参照のReduxを見ることになります。「なぜ私は単純な機能を取得するために3つのファイルをいじらないといけないのか?」本当になぜでしょうか!
人々は自分たちの苦悩をRedux, React, 関数型プログラミング, 不変性(immutability)や他の多くのモノのせいにします。それは私も理解できます。Reduxを、状態をアップデートするために”boilerplate”コードを必要としないアプローチと比較することや、Reduxは本当に複雑であると決め付けることは当然です。ある意味ではそうです。Reduxはそのようにデザインされています。
Reduxはトレードオフを含んでいます。Reduxはあなたに以下のことを求めます。
- アプリケーションの状態をプレーン・オブジェクトや配列として記述すること
- プレーン・オブジェクトとしてシステムの変更を記述すること
- 変更をハンドリングするためのロジックを純粋な関数として記述すること
React有り無しに関わらず、これらの制限はアプリケーションを構築するために必要としません。それどころか、これらはとんでもなく強い制約となります。あなたのアプリケーションの一部にでも採用するのであれば事前に注意深く考慮すべきです。
あなたはそのようにするもっともな理由をお持ちですか?
私はこれらの制限を気に入っています。なぜならこれらの制限があることによって以下のようなアプリケーションを構築することができるようになるからです。
- 余計な設定をすることなく、状態(statge)をローカルのストレージに永続化し、そこから起動すること
- 余計な設定をすることなく、サーバー上のstateを事前に満たし、それをHTML内のクライアントに送り、そこから起動すること
- プロダクトの開発者たちがエラーを再現するためにそれらをリプレイできるようにするために、ユーザーのアクションをシリアライズし、stateのスナップショットと一緒に、それらを自動化されたバグリポートに追加すること
- コードの記述方法を大幅に変更することなく共同環境を実装するためにアクションのオブジェクトをネットワーク越しに渡すこと
- コードの記述方法を大幅に変更することなく楽観的なmutationを実装するか、またはundoの履歴を維持すること
- 開発におけるstate(状態)の履歴間を移動し、コードが変更されたら、TDD風に、actionの履歴から現在のstate(状態)を再評価すること
- プロダクトの開発者たちが自分たちのアプリのためにカスタムツールを構築することができるように、全数検査を提供し、開発ツールに対する機能をコントロールすること
- ビジネスロジックの大部分を再利用している間に、代わりとなるUIを提供すること
拡張性のあるターミナル、JavaScriptのデバッガー、またはいくつかのウェブアプリケーションを使っているなら、試してみる価値があるかもしれません。また少なくともいくつかのアイデア(ちなみに、それらは新しいものではありませんが)を検討してみる価値があるかもしれません。
しかしながら、あなたが今まさにReactを学習中なのであれば、Reduxを最初の選択にしてはいけません。
その代わりReactで考えることを学びましょう。本当に必要になったら、または何か新しいことに挑戦したくなったらReduxに戻って来てください。ただし、あなたが非常に我の強いツールを使うのと同じように、用心してアプローチしてください。
もしあなたが”Redux風”の実装にプレッシャーを感じるようであれば、もしかすると自分やチームメイトは深刻になりすぎているというサインかもしれません。つまりReduxは、極端な例ではあるにせよ、あなたのツールボックスの中の数あるツールの一つににすぎません。
最後に、あなたはReduxを使わずともReduxからのアイデアを用いることができるということを忘れないでください。例えば、以下のようなローカルのstate(状態)を持ったReactコンポーネントを考えてみましょう。
このままでも完全に満足のいくものとなっています。まじめに何度でも言います。
ローカルなstate(状態)で十分です。
Reduxが含んでいるトレードオフは、「how things change(どのように物事が変更するか)」から「what happened(何が起きたか)」を分離するために間接参照を追加することです。
これが常にやっても良いことであると言えますか?いいえ、まさにトレードオフです。
例えば、以下のようにコンポーネントからreducerを抜き取ることができます。
どのように我々がnpm installすることなくReduxを使ったか気づきましたか。
stateful componentに対してこれを行うべきですか?あなたがこの追加された間接参照から利益を得るプランを持っていない限りは、おそらくnoです。プランを持っていることは、我々の時代の用語で言う🔑となります。
Redux自身はひとつのグローバルのstoreオブジェクトにreducerを「マウントする」ためのヘルパーのセットにすぎません。あなたは好きなようにReduxの一部または大部分を利用することができます。
しかし、もしあなたが何かをトレードオフするのであれば、必ず見返りに何かを得るようにしてください。
当記事は、You Might Not Need Redux – Medium (Sep 20, 2016) by Dan Abramovを日本語に翻訳したものです。
コメント