Now that our Redux store supports subscriptions, we can register to update our existing view models, allowing them to automatically stay current as our application state changes. The changes to each will be similar, but with a few variations on the common theme.
For AddVocabularyWordViewModel, we modify the constructor to initialize our members directly and then to register the required subscription:
Directly updating our member fields, instead of calling UpdateFromScreen(), avoids problems that can be caused by firing messages through our store while we’re still initializing this instance.
Our subscription is based on the CurrentScreen of our application. The RefreshFromScreen() method triggered by the subscription is fairly simple:
If the screen we’re supplied is not an AddVocabularyWordScreen, we release our subscription and do nothing; this ensures we disconnect cleanly and that the screen is available for garbage collection once the user moves on to a different screen.
After that check, we update our properties - which will in turn fire the right events to update our user interface.
For VocabularyBrowserViewModel, things are essentially the same, though we do have two different subscriptions: one for the screen, one for the vocabulary set.
Again, if the CurrentScreen changes, we disconnect - but here we need to release both subscriptions:
When the list of words changes, we update our display of words, showing all the words in alphabetical order (we apply the same ordering in our constructor, a minor violation of the DRY principle).
The last view model we need to update is WordTutorViewModel, and here the logic is slightly different. We still need to create the subscription in our constructor, as before:
But, our logic on what to do when we’re notified is quite different. Our other view models will update themselves to match our current application state, so we only need to take action here if/when the type of screen changes.
If Type implemented IEquatable<Type> then we could have used a simpler solution, creating a subscription based on the current type of the screen. But, that’s not the case - and the constraint requiring IEquatable<T> still seems reasonable.