フロントエンドアーキテクトによる注意＃1。 Reduxをそのまま使用することはできません

免責事項

親愛なる読者！ ReactとReduxが何であるかわからない場合は、さらに読むことは意味がありません。 このノートの目的を真剣に理解するには、これらのライブラリを操作する必要があります-明確に記述しようとしますが、この記事はエントリーレベルの記事ではありません。 そして、これは実践に基づく個人的な経験と意見です。

Reduxの使用の何が問題になっていますか？

それから私は書くことにしましたが、実際に私のプロジェクトや他の何千ものreduxを使用することで何が間違っていますか？ 私は、2016年4月（3年）以来、react / reduxアプリケーションを書いています。 興味深いものをすでに発見する時が来ました...そして、特に初心者向けの講義やレポートがありましたが、大人を振り返ることはなく、回顧展もありませんでした。 それまでの間、誰かが「1時間に13じゃないか」をチェックするパッケージにアスタリスクを入れます。私は一般的なステレオタイプの壁を破ります。

しかし、reduxは必要ありません！

あなたは自分が何かに正しいと言うでしょう。 2018年以降は使用できません。このトピックに関するインターネット上の記事は山ほどありますが、これまでのところ「不使用」で集団農場が得られているため、以下で理由が明らかになります。 そして、選択肢の数はスケール外であり、それ以上です。



Reduxを使用しているのは、（少なくとも反応に関して）受け入れられている標準であるため、Reduxの予測可能性と信頼性は私たちにとって重要です。 しかし、私たちは真剣にそれを見逃しています、実際にはこれで

申し立て

おそらく、ポイントについての主張が何であるかを明確にするために、最初に過去に戻って、好きなようにルーツに戻る必要があります。つまり、栄光のリデュースのドキュメントを開き、仮定を読みます。 私はそれらの最初のものだけを検討します。 それがあなたにとって興味深い場合-コメントを共有して、私はもっと多くのポイントを分析します。

唯一の真実の源...

ここに待ち伏せがあります。 もちろん、それは1つの物語があるかもしれないと言います、reduxはこのようにフラックスアーキテクチャとの違いを宣言します。 しかし、もっと広く見てみると、実際のプロジェクトでルールが守られていますか？ あなたは言うでしょう：かなり。 私は1つの側を宣言（宣言）し、プロバイダーに転送してから...



技術的には、プロセスは正しく記述されています。 しかし、私は人々は知覚、論理の歪みの影響を受けやすいと言うことができます、そしてプログラマーはまだ人間なので...あなたは私が導くことを理解しています（あなたが理解していなければ、プログラマーは知覚、論理などの歪みを起こしやすいです）

ここでの主な歪みは、同僚の多くがそうであるように、redux以外に関連して「ストア」という用語を使用しない場合、他に何も存在しないという事実に慣れているということです。

そして、ここに反応が来ます

内部状態と呼ばれる技術的な機能の1つは、この仮定に基づいていました。 便利な場所に内部状態のような記憶域を作成するだけです。 コンポーネントがあります-コンポーネントを更新し、影響を与えるメカニズムがある状態があります。 使用の違い（ストア状態、更新、ブロードキャストの変更）はほとんど目に見えません。 あなたは反対することができます：コンポーネントの状態が気に入らない理由は完全には明らかではありません。 彼は編集者のようなものではありません。 それは、内部に格納されているフラグです。



項目の名前を変更しても、本質は変わらないことを理解してください。 月曜日の大ハンマーがありますが、これは曜日にはなりません。 はい、両方の月曜日は厳しいです、他の日と大ハンマーは簡単です。 しかし、その名前から、ハンマーは打楽器ではなくなりません。



ReduxとState Reactコンポーネントの規模は異なりますが、今日使用される本質は1つです。



このように説明します：ほとんどの場合、内部状態コンポーネントからのデータは小道具を介して子になりますが、それがどれほど明白であっても、リデュースデータは、reactと統合された場合、小道具を介してコンポーネントにも入ります。 小道具を受け入れるコンポーネントの観点からは、外に何があってもかまいません。 つまり、エンドユーザー（その内部ストア）は同じです。



また、この内部状態は、それが宣言されているコンポーネントの小道具に依存しない場合があります。 次に、そのような内部状態を想像よりもさらに大きなストアにする分離を取得します。



それが真に内部であるためには、子コンポーネントにリークすることなく、宣言されているコンポーネントにのみ影響を与える必要があります。 難しいですか？ その意味はほとんど完全に失われているためです。 これは、内部状態がストアであることを示す別の兆候です。 結局のところ、「状態を保存し、変更を更新してブロードキャストする」という目的から1つのポイントを削除しただけです。変更をブロードキャストします。 すべて、状態は失われます。



つまり、内部状態を持つことの主な問題は、データの冗長性と競合し、長期的には失われ、くだらないことです。 リフトアップ（これはホスト要素の兄弟が必要なときです。そのため、ステート部分とそれを操作するすべてのロジックが親に渡され、作業ロジックの書き換えとテストに多くの時間を費やします）などのあらゆる種類のテクニックがあります。バグが表示されます、オーバーヘッド改善と多くの喜びで。 これは、開発段階でソフトウェアを損なうすべてのノイズです。 まだ販売に至っていませんが、ソフトウェアはすでにそのようなものです。



つまり、すべての兆候と問題について、複数のストーリーとこれに関連する多くの問題があります。 最後のことは、おそらく、次のとおりです。



私はreduxが持っている種類のdevtoolsについても本当に大好きです。 私が始めたとき、私たちはロガーを使用しました。ロガーはすべてのアクションを単純に統合しましたが、何が起こっているのかを完全には把握していませんでした。 さて、これが主なアシスタントであり友人です。 Reactでは、それらも表されます。 一般に、pubsubがReduxから遠いのは、devtoolsが理由です。 シロナガスクジラのアリのように。



問題 （DNAの証拠はありません）：

1. React Devtoolsを使用して内部状態を変更しても、更新や目的の結果が得られない場合があります。
2. 内部状態はredux devtoolsのtimetravelを壊します。 Reduxアーキテクチャを介して利用できるタイムトラベルのスーパー機能は、React内部状態アーキテクチャのおかげで機能しません。 内部状態はreduxの変更を気にせず、独自の状態を持っています。 タイムトラベルはうまくいきません。 一部の要素は、単に更新されない、部分的に更新される、などです。この壮大なものはすべて、非同期コード同期を伴うものです。

もちろん、練習から吸い込まれた例

新しいプロジェクトに取り組んでいるか、同僚が1年前にいくつかの機能を作成していて、それを拡張する必要があります。 一般に、他の人のコードを完成させるタスクがあります。 調査を開始し、エディターにデータがないことを理解します。 必要なデータを保存するコードにはアクション、レデューサーはありません。 そして、あなたは大切なものを探してコンポーネントのツリーを旅し始め、それらを数個でも見つけます（!!!）。 同僚に尋ねますが、答えは標準的なものです。州への書き込みを早く覚えていないので、時間がありませんでした。 あなたはソースに行き、その現在の状態が改訂を伴わないことを理解します。 動作するテスト済みのコードを書き換えて、変更を加え、新しい機能を追加しています。



内部状態という形での有害な代替物の存在は、その汚い行為をします。 結局のところ、今では安価であり、1年で何が起こるかは関係ありません。

比metaが少ない

それは悪い食べ物のように見えます-それは美味しくて安いように見えますが、1年か3年後には-消化管は従うのをやめ、自分の人生を生きます。 あなたは以前の健康を取り戻すために多くの時間とお金を費やし、常にこれで成功するとは限りません。



ReduxとReact Internal Stateは 、1つのニッチにおける大企業と中小企業のように競合他社です。 主な製品はデータと影響力です。 ソフトウェアは製品の消費者です。 多くの類推がありますが、本質は同じままです-ソフトウェアを開発するとき、競争は必要ありません。



私たちはプログラムコードの「独裁者」であり、競争は抑制され、自由市場は禁止され、計画された経済と国家の独占が消費者を支配すべきです。



エヘム、何かが私を退屈させた。 一般に、すべてが計画どおりに進む必要があります。 スプリント、リリースなどがあり、ソフトウェアには有限のコストと市場への寿命/参入があります。 これは非常に重要であり、船の暴動、図書館の蜂起を許可することはできません。

結論は簡単です。

reduxで他のリポジトリを使用しないでください。 例外は、非常に孤立したケースにしかできません。 たとえば、原則として、対応するレイヤーなしではreduxによって制御されず、影響を与えないコンポーネント。

例

あるブランチでスタンドアロンモジュールを開発し、別のブランチでストアをリファクタリングしました。一般に、ストアと状態を管理するためのアプローチは、公開用の別のトピックです。 モジュールのリファクタリングを開始しましたが、モジュールの作成の開始時と終了時の両方で、テストとウィザードへのリファクタリングはなくなりませんでした。 リファクタリングは大規模であり、計画が必要な思慮深いリコースが必要です-一般的に、あなたはただリファクタリングしてリファクタリングすることはできません。









したがって、ストアで今後行われる変更について知っていたので、新しい機能を開発するためにそれを使用しませんでした。 これにより、放棄されたリファクタリングとテストを更新するコストが増加する場合があります。

私がしたこと：最小限のデータにサインアップしました。 データとその構造はリファクタリングの影響を受けず、それらを生成したコードは影響を受けたり保存されたりしました。エディターにバイトを書きませんでした。 ユーザーがログインしているかどうか、さらにいくつかのフィールドを確認します。



ニーズに合わせて、PubSubをチャネルとシンプルなAPIで洗浄しました。 はい、はい、pubsab。 通常の痛みを伴う痛みの欠如。 タイムトラベル-痛み。 一般的に、開発ツールの形でchromeの拡張機能を作成する予定であり、githubでreduxの競合として再実装を公開することが可能です。 reduxについては、この記事では取り上げませんが、PubSubには実際にはありません。 reduxロガーを思い出したという事実に加えて...



したがって、モジュールには独自のストレージ、サーバーへの独自の接続があります。



つまり、reduxはモジュールにまったく影響せず、実際にはこのストレージに影響を与えることはできません（サブスクリプションには3つのフィールドしかありません）が、モジュールとPubSubの両方はreduxに影響しません。 この分離は競争を排除します。



「データをどこに保存するのか？」という質問は、私が今まで経験したことのないモジュールを開発するときです。 しかし、内部状態に対するリデュースに関しては、多くの場合、この質問はほとんど常に発生します。 私はこの質問にきっぱりと答えることにしました。



私の建築的意見は：



データをredux（all-all、 "internal"でも）にのみ保存します。反応プロジェクトにメインリポジトリとして接続されている場合、競合するリポジトリを使用しないでください。 これにより、このライブラリとそのdevtoolsの信頼性と影響が増加します（タイムトラベルとすべてのデータを段階的に追跡することで、開発と潜在的な問題の検索が高速化されます-同期変更はより速く、非同期になりやすくなります）。



おそらく、内部状態を開発から完全に除外するライブラリを追加する価値があるでしょうか？ または、内部状態をreduxからの選択などに置き換えますか？ 私はそのようなものを1年前に書き始め、90パーセントを終え、さらに1つのレポートを実施しました。 何て言うの？ それらが必要ですか？



このメモを楽しんだことを願っています:)