commit d49e833e91671510b7cde2a21c17659fa5f5eb03
author Ben Rohlfs <brohlfs@google.com> Thu Apr 20 22:40:04 2023 +0200
committer Ben Rohlfs <brohlfs@google.com> Mon Apr 24 10:02:26 2023 +0200
tree 1681b474197bbf02a6cb6848b47679de3c1bc743
parent e16a9c3b83a9dcff63f2ef94b63374df4dd32a96

Remove `viewStateChanged()` method from gr-change-view

The deed is done. This was the ultimate target of a large chain of
refactorings: Do not let the change view handle view state updates in a
complicated tree of paths, but instead let the change model react in
specific independent subscriptions. And let the view just subscribe to
model updates.

The major missing change that was still needed, was the handling of
firing and handling reload events. Unfortunately clearing the patchset
and forcing a reload was also been handled by a `reload` event, but
clearing the patchset is a view state change, so this should be a
direct command to the model. So we have looked at all `fireReload()`
and `fireReload(true)` instances and checked which one is more
appropriate: Keeping firing the "soft" reload or requesting a new
view state.

One issue was that the `forceReload` URL parameter was only handled by
the change view. We are handling this now in the change view model.

We have unified the entire reload handling in the change view model:
The `reload` event, the `reload()` method of the view model and the
`forceReload` URL parameter all end up in the same place: We are
always resetting the view state to `undefined` in order to trigger
a reload. That is very robust and reliable and allows us to also get
rid of some dedicated `reload$` observables that we don't need anymore.

Stop logging `change-view-re-rendered`. We don't need that anymore.

Release-Notes: skip
Change-Id: Ie6319089dee7586c04c01b2ae91c18bc75f0d85d