As Element Call grows in complexity, it has become a pain point that our business logic remains so tightly coupled to the UI code. In particular, this has made testing difficult, and the complex semantics of React hooks are not a great match for arbitrary business logic. Here, I show the beginnings of what it would look like for us to adopt the MVVM pattern. I've created a CallViewModel and TileViewModel that expose their state to the UI as rxjs Observables, as well as a couple of helper functions for consuming view models in React code. This should contain no user-visible changes, but we need to watch out for regressions particularly around focus switching and promotion of speakers, because this was the logic I chose to refactor first.
34 lines
934 B
TypeScript
34 lines
934 B
TypeScript
/*
|
|
Copyright 2023 New Vector Ltd
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
*/
|
|
|
|
import { Subject } from "rxjs";
|
|
|
|
/**
|
|
* An MVVM view model.
|
|
*/
|
|
export abstract class ViewModel {
|
|
protected readonly destroyed = new Subject<void>();
|
|
|
|
/**
|
|
* Instructs the ViewModel to clean up its resources. If you forget to call
|
|
* this, there may be memory leaks!
|
|
*/
|
|
public destroy(): void {
|
|
this.destroyed.next();
|
|
this.destroyed.complete();
|
|
}
|
|
}
|