Redux

Reactは,状態属性(props)を用いた素子セル開発アーキテクチャを学習した.
冗長性では、構成部品をステータスから分離するモードを熟知する必要があります.

Reduserの表示

Reduceの最も顕著な特徴は「単一ショップ、複数のReducer」政策である.システムドメイン層としての店舗ですべての(大部分の)状態を管理できるアーキテクチャの上で、店舗も増加するコードライブラリに適応するために肥大化しやすくなります.この場合、1つの店を複数の店に分割します.
リカバリでは、1つのショップを保持しながら、ステータス処理の責任をショップの下流にあるリカバリ担当者に任せる「単一リカバリ、複数リカバリ」ポリシーが選択されています.Reduceでは、ショップはコンポーネントとReduserを接続する非常に薄い層にすぎません.ステータスとステータスを処理する行為は、ショップではなく小売業者が責任を負います.店には複数の小売業者がいます.各リダイレクタが処理するステータスは、最終的にトップリダイレクタによってシステムのステータスツリーを生成し、サブスクリプションストアのサブスクライバに渡される.

最下位の論理を分離するのではなく、より高いレベルに店を抽象化することで責任を分散します.以下の例のコードから、Ridexでは、店舗に内部エンティティが見えないことがわかります.李杜瑟しか見えない.状態処理ロジックを記述するだけで、残りはRidexが独自に組み合わせます.

import { createStore } from 'redux'

function counter(state=0, action) {
  	switch (action.type) {
      case 'increment : 
        return state + 1;
        
      case 'squre' :
        return state * state;
        
      default : 
        return state;
    }
}
const store = createStore(counter);

reducerと純関数についての思考

リデスの公式ドキュメントの例は、純粋な関数を積極的に利用しています.純関数とは、次のような特徴を持つ関数です.

関数以外のデータまたは変数を変更して、予期せぬ結果を避ける必要があります.

と同じ入力データのセットが提供される場合、常に同じ演算結果を返さなければならない.

Reduserの純粋さを保つということは,システムが複雑になってもReduserの単純さをできるだけ保つことである.

resolvers.deleteComponent = (prevState, { targetId }) => {
  const { order, compMap } = prevState;
  const updatedOrder = deleteComponent(order, targetId);
  
  return Immutable
        .fromJS(prevState)
        .merge({
            order: updatedOrder,
            focusCompId: ""
        })
        .deleteIn(["compMap", targetId])
        .toJSON();
};

入力を受信すると,入力値を処理し,新しい状態を結果として返すことができる.入力値を渡す以外は、関数の実行中に外部条件の影響を受けません.やることは簡単で、予測しやすく、テストしやすい.李徳思が誇示したタイムトラベルが調整できるのも、李徳洙のこのような特性のためだ.

it("컴포넌트 목록에서 원하는 컴포넌트 하나를 삭제할 수 있다.", () => {
    // given
    const deleteTarget = 'target';
    const action = compListAction.deleteComponent(deleteTarget);

    // when
    const { order, compMap } = compListReducer(initState, action);

    // then
    order.should.not.include(deleteTarget);
    should.not.exist(compMap[deleteTarget]);
});

しかし,再コンストラクタは関数であるため,動作とデータを結合したドメインモデルの構築は困難である.これにより、設計上、不慣れな点(例えば、データのアイデンティティがあいまいであることをどのように定義するか、またはドメイン層のフロントエンドでAJAXリクエストを処理してデータを取得する必要がある)が発生します.
誘電体が伝達する値が同じであれば、誘電体が返す値も同じでなければならない.このため、非同期通視グラデーション効果を発生させることができる挙動はリーダにはない.
ビジネスロジックは、データの処理に近い場所にあることが望ましいため、reducerアプリケーションのビジネスロジックはreducerの場所にあることが望ましい.処理する論理の性質によっては、reducer内部の論理が非常に複雑になる可能性があるため、reducer内で他の複数の関数を呼び出すことが多い.
この点で誤解すべきではない点は,Reduserを「純粋」にするためには,必ずしも関数を堅持する必要はないということである.オブジェクトを利用すると、いつでもリーダーを純粋にすることができます.

ソース

原文を調べる