2

状態管理を行う必要がある比較的単純なアプリを作成しています。すべてのドキュメントと多くの書き直しを調べた後、クラシック プロバイダーや Riverpods プロバイダーなどの状態管理用に提供されているツールを実際に構造化して使用する方法を理解するための助けが必要です。私の質問は、状態を保持するモデルの配置、それらのオブジェクトのネスト、およびウィジェット ツリーの一部のみの再描画に関するものです。

私のプロジェクトは、ガソリンスタンドと支払った金額の共有ログを保持できるモバイルアプリです。1 人または複数の人と車両を共有する場合、全員が燃料エントリが表示されるプールに入ります。ユーザー、ログ エントリ、およびプールのモデルがあります。ユーザーがログインすると、使用可能な多数のプールを取得して保存する必要があり、選択後、選択したプールのメンバーとログを取得する必要があります。たとえば、ユーザーの名前や特定のログ エントリが更新された場合、現在のビューを更新する必要がある場合があります。

ChangeNotifierProviderさて、現在のコードは、ウィジェット ツリーのルートにあるによって提供されるプール モデルに状態の多くが格納される混乱した状態になっています。UI の更新をできるだけ少なくする必要があるという印象を受けていたので、状態をさまざまなモデルに分割しようとしました。これらのモデルは互いに入れ子になっています。たとえば、LogEnriesプール モデルの一部ですが、それ自体はChangeNotifier. アイデアは、状態の一部を選択的に更新してリッスンできるようにすることでした。notifyListeners()これにより、プールモデル/状態オブジェクトの外部から呼び出す必要がある恐ろしいコードが発生しました。状態管理を書き直して状況を改善したいと考えています。

さて、私の質問ですが、図書館を作った魔法の神々を効率的かつ喜ばせるために、ある構造物が一般的に(または具体的には私の状態を)どのように状態にしているのでしょうか?2年または1年前のこのスタックオーバーフローの質問は同様の質問をしており、提供された回答は次のいずれかを行うことを推奨しています:

  1. 状態をネストしたままにし、 でモデルを互いに注入しChangeNotifierProviderますが、提供されたオブジェクトがモデルである場合、明らかにそれは良くありません
  2. プロバイダーがツリーの最上位にある 1 つの状態オブジェクトにすべてを配置し、セレクターを使用して、影響を受ける UI の部分のみを更新します。
  3. モデルをネストしますが、ルートを不変オブジェクトとして提供し、関数を呼び出して何かをコピーすることで状態を更新するだけです

私は別のアプローチが

  1. 最近リリースされた riverpod パッケージを使用して、あらゆるニーズに対応する多くのプロバイダーを作成してください。

現在、これらのアプローチのどれがより優れているか、有効であるか、またはそれらがすべて完全に機能するかどうかはわかりません。対応するアプローチに関する私の質問は次のとおりです。

  1. それらをどの順序でネストしますか?ルート状態オブジェクトのプール、プール モデルのログ エントリを直感的にネストしましたが、依存関係に関しては、おそらく User->AppState->selectedPool->Logs に移動する必要があり、logEntry.selectedPool.appState.user. 奇妙に感じます。

  2. これはうまくいくかもしれませんが、私は常に 1 つのモデルで全体の状態を取得します (これはおそらく、私のユース ケースではそれほど大きくありません)。を使用して UI の一部のみを更新することもできますが、何かが変更されたかどうかを確認できるようにする必要がSelectorあるため、可変オブジェクトを使用すると問題が発生したと思います。Selectorまた、私が理解している限り、特に選択したものしか使用できず、後で UI の更新に使用するものとは異なるプロパティをリッスンすることはできませんでした。

  3. 上記と同じで、定型コードもたくさんあります。

  4. Riverpod とそのプロバイダーは本当にクールに見えるので、これは最もエキサイティングなようです。ref.watch()しかし、状態をネストするか、すべてをグローバルに提供して、作成メソッドにいくつかのものを注入しますか? 個別にリッスンしたいすべての変更に対して新しいプロバイダーを作成しますか、それともオブジェクトを取得したらそれを理解する方が安価ですか? そして、Riverpod は ChangeNotifier に相当するため、StateNotifier は値を 1 つしか持たないため (私が思うに?)、必要な重要な情報ごとに新しいプロバイダーを作成する必要があるでしょうか?

お気づきかもしれませんが、私は多くのことを調べようとしましたが、すべての手法をコードのデモのサイズを超えて実際のプロジェクトに変換する方法を完全には理解していません。一般的に状態管理を構築するための正しいアプローチを誰かが説明してくれたら、非常に感謝します。どのアプローチが私の特定の状況に最適であり、最も重要なこととして、他のアプローチに反対する理由は何でしょうか。私が犯した間違いを指摘することを躊躇しないでください。stackoverflow はこれが問題にならないことを示唆しているという評判があります。誰かが私のコードを見たい場合は、AppState モデルから始めていくつかの機能を作り直して、より良いモジュール化に向けて取り組み始めたブランチがあります。

4

0 に答える 0