ReactiveUIの概要：コレクション

こんにちは、Habr！



パート1：ReactiveUIの概要：ViewModelのプロパティをポンピングする



前の記事で、ViewModelのプロパティと、ReactiveUIを使用してそれらを使用してできることについて説明しました。 プロパティ間の依存関係を整理し、ビューモデルの1か所に、プロパティ間の依存関係が含まれている情報を収集しました。

今回は、プロパティについてもう少し話してから、コレクションに移りましょう。 通常のコレクションにはどんな問題があるのか​​、なぜ変更を通知して新しいコレクションを作成する必要があったのかを理解してみましょう。 そして、もちろん、それらを使用してみてください。

プロパティに関するいくつかの言葉

メイントピックに移る前に、プロパティについていくつか説明します。 前回、次の構文に到達しました。

private string _firstName; public string FirstName { get { return _firstName; } set { this.RaiseAndSetIfChanged(ref _firstName, value); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各プロパティに6行のコードを費やすことは、特にそのようなプロパティが多く、実装が常に同じ場合は、かなり無駄です。 C＃では、この問題を解決するために、自動プロパティが一度に追加され、より簡単に生活できるようになりました。 私たちのケースでは何ができますか？

コメントでは、 Fodyが言及されました-プロジェクトのビルド後にILコードを変更できるツールです。 たとえば、変更通知を自動プロパティの実装に追加します。 また、ReactiveUIには、対応する拡張機能であるReactiveUI.Fodyもあります。 使ってみよう。 ちなみに、従来の実装の拡張機能であるPropertyChangedもありますが、 RaiseAndSetIfChanged（）を呼び出す必要があるため、私たちには適していません。



NuGet：> Install-Package ReactiveUI.Fodyからインストールします

FodyWeavers.xmlがプロジェクトに表示されます。 インストール済みの拡張機能を追加します。

 <?xml version="1.0" encoding="utf-8" ?> <Weavers> <ReactiveUI /> </Weavers>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、プロパティを変更します。

 [Reactive] public string FirstName { get; set; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このツールを使用すると、ObservableAsPropertyHelper <>に基づいてFullNameプロパティを実装することもできます。 この方法はGitHubのドキュメントで説明されていますが、ここでは省略します。 2行は完全に受け入れられるオプションだと思います。RePropertyUI.Fodyがこのプロパティを正しく実装できるようにするToProperty（）の代わりに、サードパーティのメソッドを使用したくありません。



何も壊れていないことを確認します。 どうやって？ 単体テストで確認します。 ReactiveUIはそれらに友好的であり、 MVVMフレームワーク<...>がエレガントでテスト可能なユーザーインターフェースを作成するのは、何のためでもありません.... イベントのトリガーを確認するには、手動でサインアップし、トリガーされたときにデータを保存してから処理する必要はありません。

Observable.FromEventPattern（）は、イベントトリガーをすべての必要な情報とともにIObservable <>に変換するのに役立ちます。 IObservable <>をイベントのリストに変換し、正確性を確認するには、拡張メソッド.CreateCollection（）を使用すると便利です。 彼は、ソースがOnComplete（）を呼び出すか、Dispose（）を呼び出すまで、IObservable <>を経由した要素が追加されるコレクションを作成します。この場合、トリガーされたイベントに関する情報が追加されます。

コレクションはすぐに返され、後で非同期的に要素が追加されることに注意してください。 この動作は、たとえば.ToList（）とは異なります。.ToList（）は制御を返さないため、コレクション自体はOnComplete（）に返されます。OnComplete（）は、通常のイベントサブスクリプションの場合は永遠に待機します。

 [Test] public void FirstName_WhenChanged_RaisesPropertyChangedEventForFirstNameAndFullNameProperties() { var vm = new PersonViewModel("FirstName", "LastName"); var evendObservable = Observable.FromEventPattern<PropertyChangedEventHandler, PropertyChangedEventArgs>( a => vm.PropertyChanged += a, a => vm.PropertyChanged -= a); var raisedEvents = evendObservable.CreateCollection(); using (raisedEvents) { vm.FirstName = "NewFirstName"; } Assert.That(vm.FullName, Is.EqualTo("NewFirstName LastName")); Assert.That(raisedEvents, Has.Count.EqualTo(2)); Assert.That(raisedEvents[0].Sender, Is.SameAs(vm)); Assert.That(raisedEvents[0].EventArgs.PropertyName, Is.EqualTo(nameof(PersonViewModel.FirstName))); Assert.That(raisedEvents[1].Sender, Is.SameAs(vm)); Assert.That(raisedEvents[1].EventArgs.PropertyName, Is.EqualTo(nameof(PersonViewModel.FullName))); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストスクリプト自体（プロパティに新しい値を設定する）はusingの内部で実行され、その後でチェックが行われます。 これは、チェック中に一部のイベントが誤って機能せず、コレクションが損なわれないようにするために必要です。 もちろん、これはしばしば必要ではありませんが、時には重要になる場合があります。



IObservable <> Changedが同じものを返すことを確認しましょう。

 [Test] public void FirstName_WhenChanged_PushesToPropertyChangedObservableForFirstNameAndFullNameProperties() { var vm = new PersonViewModel("FirstName", "LastName"); var notifications = vm.Changed.CreateCollection(); using (notifications) { vm.FirstName = "NewFirstName"; } Assert.That(vm.FullName, Is.EqualTo("NewFirstName LastName")); Assert.That(notifications, Has.Count.EqualTo(2)); Assert.That(notifications[0].Sender, Is.SameAs(vm)); Assert.That(notifications[0].PropertyName, Is.EqualTo(nameof(PersonViewModel.FirstName))); Assert.That(notifications[1].Sender, Is.SameAs(vm)); Assert.That(notifications[1].PropertyName, Is.EqualTo(nameof(PersonViewModel.FullName))); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして...テストは落ちました。 しかし、プロパティの変更に関する情報のソースを変更しました！ テストが失敗した理由を理解してみましょう。

 vm.Changed.Subscribe(n => Console.WriteLine(n.PropertyName)); vm.FirstName = "OMG";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、我々は得る：

氏名

名

行くぞ これはフレームワークのバグではなく、実装の詳細のようです。 これは理解できます。両方のプロパティはすでに変更されており、通知の順序は重要ではありません。 一方で、イベントの順序と一致せず、期待を満たしていないため、混乱する可能性があります。 もちろん、通知の順序に基づいてアプリケーションロジックを構築することは明らかに悪い考えです。 しかし、たとえば、アプリケーションログを読み取ると、依存関係プロパティが依存関係の変更前に変更について通知していることがわかります。 したがって、この機能を忘れないでください。

そのため、ReactiveUI.Fodyが適切に動作し、コードの量を大幅に削減するようにしました。 次にそれを使用します。

---

それでは、コレクションに移りましょう

INotifyPropertyChangedインターフェイスは、既知のように、ビューモデルのプロパティを変更する場合に使用されます。たとえば、何かが変更され、インターフェイスを再描画する必要があることを視覚要素に通知するために使用されます。 しかし、ビューモデルに多くの要素のコレクション（ニュースフィードなど）があり、既に表示されているものに新しいエントリを追加する必要がある場合はどうすればよいでしょうか。 コレクションが存在するプロパティが変更されたことを通知しますか？ 可能ですが、インターフェイス内のリスト全体が再配置されることになり、特にモバイルデバイスの場合は、操作が遅くなる可能性があります。 いいえ、それは機能しません。 コレクション自体が何かが変更されたことを通知する必要があります。 幸いなことに、素晴らしいインターフェースがあります：

 public interface INotifyCollectionChanged { /// <summary>Occurs when the collection changes.</summary> event NotifyCollectionChangedEventHandler CollectionChanged; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コレクションがそれを実装する場合、追加/削除/置換などの場合 CollectionChangedによってトリガーされるイベント。 また、ニュースリストを再度作成し直してレコードのコレクション全体を確認する必要はありません。イベントを通じて追加された新しい要素を追加するだけです。 .NETにはそれを実装するコレクションがありますが、ReactiveUIについて話しています。 何が入っているの？

インターフェイスのセット全体：IReactiveList <T>、IReadOnlyReactiveList <T>、IReadOnlyReactiveCollection <T>、IReactiveCollection <T>、IReactiveNotifyCollectionChanged <T>、IReactiveNotifyCollectionItemChanged <T>。 ここではそれぞれの説明はしませんが、それらが何であるかという名前から明確にすべきだと思います。

しかし、実装をさらに詳しく見てみましょう。 会う：ReactiveList <T>。 彼はそれらすべてを実装しています。 コレクションの変更を追跡することに興味があるので、このクラスの対応するプロパティを見てみましょう。



かなりたくさん！ 要素の追加、削除、移動、要素の数、コレクションの空、リセットの必要性を監視します。 これをすべて詳細に検討してください。 もちろん、INotifyCollectionChanged、INotifyPropertyChanged、およびそれらのペアになった* Changindからのイベントも実装されますが、それらについては説明しません。これらは、図に示されている「観測可能な」プロパティと並行して動作し、そこにはユニークなものはありません。

手始めに、簡単な例。 通知のいくつかのソースをサブスクライブし、コレクションを少し操作します。

 var list = new ReactiveList<string>(); list.BeforeItemsAdded.Subscribe(e => Console.WriteLine($"Before added: {e}")); list.ItemsAdded.Subscribe(e => Console.WriteLine($"Added: {e}")); list.BeforeItemsRemoved.Subscribe(e => Console.WriteLine($"Before removed: {e}")); list.ItemsRemoved.Subscribe(e => Console.WriteLine($"Removed: {e}")); list.CountChanging.Subscribe(e => Console.WriteLine($"Count changing: {e}")); list.CountChanged.Subscribe(e => Console.WriteLine($"Count changed: {e}")); list.IsEmptyChanged.Subscribe(e => Console.WriteLine($"IsEmpty changed: {e}")); Console.WriteLine("# Add 'first'"); list.Add("first"); Console.WriteLine("\n# Add 'second'"); list.Add("second"); Console.WriteLine("\n# Remove 'first'"); list.Remove("first");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果が得られます。

＃「最初」を追加

カウント変更：0

追加前：最初

変更されたカウント：1

変更されたIsEmpty：False

追加：最初



＃「秒」を追加

カウント変更：1

追加前：2番目

変更されたカウント：2

追加：2番目



＃「最初」を削除

カウント変更：2

削除する前：最初

変更されたカウント：1

削除済み：最初

追加または削除されたもの、要素の数の変更、コレクションの空の兆候が通知されます。

さらに：

-ItemsAdded / ItemsRemoved / BeforeItemsAdded / BeforeItemsRemovedは、追加または削除されたアイテム自体を返します

-CountChanging / CountChangedは、変更前後の要素の数を返します

-IsEmptyChangedは、コレクションの空の属性の新しい値を返します

微妙な点が1つあります

これまでのところ、すべてが予測可能です。 ここで、コレクション内のレコードの数をカウントするのは、追加と削除の通知に基づいてのみであると想像してください。 何がもっと簡単だろうか？

 var count = 0; var list = new ReactiveList<int>(); list.ItemsAdded.Subscribe(e => count++); list.ItemsRemoved.Subscribe(e => count--); for (int i = 0; i < 100; i++) { list.Add(i); } for (int i = 0; i < 100; i+=2) { list.Remove(i); } Assert.That(count, Is.EqualTo(list.Count));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストは成功しました。 コレクションを埋める原則を変更し、一度に多くの要素を追加します。

 list.AddRange(Enumerable.Range(0, 10)); list.RemoveAll(Enumerable.Range(0, 5).Select(i => i * 2));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

成功しました。 キャッチはないようです。 ちょっと待って…

 list.AddRange(Enumerable.Range(0, 100)); list.RemoveAll(Enumerable.Range(0, 50).Select(i => i * 2));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ああ！ テストは失敗し、count == 0になりました。何かを考慮していないようです。 正しくしましょう。



問題は、ReactiveList <T>は見かけほどプリミティブに実装されていないことです。 コレクションが大幅に変更されると、通知をオフにし、すべての変更を行い、通知をオンに戻し、リセット信号を送信します。

 list.ShouldReset.Subscribe(_ => Console.WriteLine("ShouldReset"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜこれが行われるのですか？ コレクションが大幅に変更される場合があります。たとえば、100個の要素が空のコレクションに追加されたり、要素の半分が大きなコレクションから削除されたり、完全に削除されたりします。 この場合、小さな変更すべてに応答する意味はありません。一連の変更の終了を待って、コレクションが完全に新しいかのように反応するよりもコストが高くなります。

最後の例では、これが起こります。 ShouldResetのタイプはIObservable <Unit>です。 ユニットは、オブジェクトの形式でのみ、本質的に無効です。 イベントのサブスクライバーに通知する必要がある状況で使用され、発生することが重要であるだけで、追加データを送信する必要はありません。 ちょうど私たちの場合。 サブスクライブした場合、挿入および削除操作の後にリセット信号を受信したことがわかります。 したがって、カウンターを正しく更新するには、例を少し変更する必要があります。

 list.ItemsAdded.Subscribe(e => count++); list.ItemsRemoved.Subscribe(e => count--); list.ShouldReset.Subscribe(_ => count = list.Count);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでテストに合格し、すべて正常になりました。 いくつかの通知が来てこれらの状況を処理しないかもしれないことを忘れないでください。 そして、もちろん、コレクションが大きく変化するような状況をテストすることを忘れないでください。

通知抑制ルールの変更

コレクションに大きな変化があると、リセット信号が発生することがわかりました。 このプロセスはどのように制御できますか？

ReactiveList <T>コンストラクターには、double resetChangeThreshold = 0.3というオプションの引数が1つあります。 リストの作成後、ResetChangeThresholdプロパティを使用してリストを変更できます。 どのように使用されますか？ 追加/削除されたアイテムの数をコレクション自体のアイテムの数で割った結果がこの値よりも大きく、追加/削除されたアイテムの数が厳密に10より大きい場合、変更の通知は抑制されます。将来変更されません。

この例では、 100/ 0> 0.3および50/100> 0.3なので、通知は両方の時間で抑制されました。 当然、ResetChangeThresholdを変更して、コレクションを特定の使用場所に置き換えることができます。

通知をどのように抑制するのですか？

カウンターを使用した最初の例では、次のコードを見ました。

 for (int i = 0; i < 100; i++) { list.Add(i); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、アイテムが1つずつ追加されるため、変更通知は常に送信されます。 しかし、私たちは多くの要素を追加しており、しばらくの間通知を抑制したいと考えています。 どうやって？ SuppressChangeNotifications（）を使用します。 using内のすべてが変更通知をトリガーしません：

 using (list.SuppressChangeNotifications()) { for (int i = 0; i < 100; i++) { list.Add(i); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コレクション自体の要素の変更についてはどうですか？

ReactiveList <T>には、ItemChangedおよびItemChangingという通知のソースがあります-要素自体への変更。 それらを使用してみましょう：

 var list = new ReactiveList<PersonViewModel>(); list.ItemChanged.Subscribe(e => Console.WriteLine(e.PropertyName)); var vm = new PersonViewModel("Name", "Surname"); list.Add(vm); vm.FirstName = "NewName";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何も起こりませんでした。 だまされており、ReactiveListは要素の変更を実際に監視していませんか？ はい、ただしデフォルトでのみ。 彼が要素内の変更を追跡するには、この機能を有効にするだけです。

 var list = new ReactiveList<PersonViewModel>() { ChangeTrackingEnabled = true };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これですべてが機能します：

氏名

名

また、作業中にオンとオフを切り替えることができます。 オフにすると、アイテムに対する既存の内部サブスクリプションが削除され、オンにすると、アイテムが作成されます。 当然、サブスクリプションアイテムの追加/削除時にも削除および追加されます。

---

継承されたコレクション

既存のコレクションから要素の一部のみを選択したり、並べ替えたり、変換したりする必要がある場合、どのくらいの頻度で状況が発生しますか？ 元のコレクションを変更するときは、依存するコレクションを変更します。 このような状況は珍しくなく、ReactiveUIにはこれを簡単に行えるツールがあります。 彼の名前はDerivedCollectionです。 これらはReactiveListから継承されるため、機能は同じですが、そのようなコレクションを変更しようとすると例外がスローされます。 コレクションは、そのベースコレクションが変更されたときにのみ変更できます。

変更の通知を再度検討することはありません。すべてが以前と同じです。 基本コレクションに適用できる変換を見てみましょう。

 var list = new ReactiveList<int>(); list.AddRange(Enumerable.Range(1, 5)); var derived = list.CreateDerivedCollection( selector: i => i*2, filter: i => i % 2 != 0, orderer:(a, b) => b.CompareTo(a)); Console.WriteLine(string.Join(", ", list)); Console.WriteLine(string.Join(", ", derived)); list.AddRange(Enumerable.Range(2, 3)); Console.WriteLine(string.Join(", ", list)); Console.WriteLine(string.Join(", ", derived));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

値を変換し、元の要素をフィルター処理してから（変換前に！）、変換された要素にコンパレーターを渡すことができることがわかります。 さらに、セレクターのみが必要で、残りはオプションです。

INotifyCollectionChangedだけでなく、IEnumerable <>をベースコレクションとして使用できるようにするメソッドオーバーロードもあります。 しかし、その後、継承されたコレクションにリセット信号を取得する方法を提供する必要があります。

ここで、継承されたコレクションは元のコレクションから奇数の要素を取得し、その値を2倍にして、大きいものから小さいものに並べ替えます。 コンソールには次のようになります。

1、2、3、4、5

10、6、2



1、2、3、4、5、2、3、4

10、6、6、2

お楽しみに

今回は、最後の部分で説明されていないプロパティの操作の詳細について説明しました。 彼らは、プロパティの実装が1行を占めるようにし、変更に関する通知の順序が信頼できないことを確認しました。 主なテーマはコレクションでした。 ReactiveListが変更されたときにReactiveListから取得できる通知を把握しました。 通知が自動的に抑制される理由と条件、および自分の手で通知を抑制する方法を見つけました。 最後に、継承されたコレクションを使用して、変更に応じてベースコレクション内のデータをフィルター処理、変換、および並べ替えできることを確認しました。

次のパートでは、チームについて話し、ビューモデルのテストの問題を検討します。 これに関連する問題とその解決方法を確認します。 次に、View + ViewModelバンチに進み、既に説明したツールを使用する小さなGUIアプリケーションを実装してみましょう。



じゃあね！