mirrors/element-web
1
0
Fork 0
mirror of https://github.com/element-hq/element-web.git synced 2024-12-16 05:51:33 +03:00
Code Issues Projects Releases Packages Wiki Activity
element-web/src/stores/room-list/RoomListStore2.ts

514 lines
23 KiB
TypeScript
Raw Normal View History

Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
/*
Copyright 2018, 2019 New Vector Ltd
Copyright 2020 The Matrix.org Foundation C.I.C.
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.
*/
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
import { MatrixClient } from "matrix-js-sdk/src/client";
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
import SettingsStore from "../../settings/SettingsStore";
Implement breadcrumb notifications and scrolling
2020-07-01 01:24:46 +03:00
import { DefaultTagID, OrderedDefaultTagIDs, RoomUpdateCause, TagID } from "./models";
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
import TagOrderStore from "../TagOrderStore";
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
import { AsyncStore } from "../AsyncStore";
Early handling of dispatched events A possible approach to handling the various triggers for recategorizing rooms.
2020-05-04 18:06:34 +03:00
import { Room } from "matrix-js-sdk/src/models/room";
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
import { IListOrderingMap, ITagMap, ITagSortingMap, ListAlgorithm, SortAlgorithm } from "./algorithms/models";
Use the new TS dispatcher
2020-05-14 22:45:17 +03:00
import { ActionPayload } from "../../dispatcher/payloads";
import defaultDispatcher from "../../dispatcher/dispatcher";
Update badge counts in new room list as needed
2020-05-26 00:54:02 +03:00
import { readReceiptChangeIsFor } from "../../utils/read-receipts";
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
import { IFilterCondition } from "./filters/IFilterCondition";
import { TagWatcher } from "./TagWatcher";
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
import RoomViewStore from "../RoomViewStore";
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
import { Algorithm, LIST_UPDATED_EVENT } from "./algorithms/Algorithm";
Handle room invites as new rooms We wouldn't have seen them before, so might as well treat them as new instead of tag changes.
2020-06-30 23:23:00 +03:00
import { EffectiveMembership, getEffectiveMembership } from "./membership";
Add a layout reset function For https://github.com/vector-im/riot-web/issues/14265 Intended to be accessed via `mx_RoomListStore2.resetLayout()`
2020-07-01 03:52:13 +03:00
import { ListLayout } from "./ListLayout";
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
import { isNullOrUndefined } from "matrix-js-sdk/src/utils";
Move list layout management to its own store This is more general maintenance than performance as the RoomList doesn't need to be generating layouts for the sublists, and it certainly doesn't need to be creating a bunch of extra ones. The sublists are perfectly capable of getting their own layout instance and using it, and we are perfectly able to limit the number of these things we create through the session's lifespan.
2020-07-09 03:27:50 +03:00
import RoomListLayoutStore from "./RoomListLayoutStore";
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
import { MarkedExecution } from "../../utils/MarkedExecution";
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
interface IState {
tagsEnabled?: boolean;
}
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
/**
* The event/channel which is called when the room lists have been changed. Raised
* with one argument: the instance of the store.
*/
export const LISTS_UPDATE_EVENT = "lists_update";
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
export class RoomListStore2 extends AsyncStore<ActionPayload> {
private _matrixClient: MatrixClient;
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
private initialListsGenerated = false;
private enabled = false;
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
private algorithm = new Algorithm();
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
private filterConditions: IFilterCondition[] = [];
private tagWatcher = new TagWatcher(this);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
private updateFn = new MarkedExecution(() => this.emit(LISTS_UPDATE_EVENT));
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
private readonly watchedSettings = [
'feature_custom_tags',
];
constructor() {
super(defaultDispatcher);
this.checkEnabled();
for (const settingName of this.watchedSettings) SettingsStore.monitorSetting(settingName, null);
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
RoomViewStore.addListener(this.onRVSUpdate);
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
this.algorithm.on(LIST_UPDATED_EVENT, this.onAlgorithmListUpdated);
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
public get orderedLists(): ITagMap {
if (!this.algorithm) return {}; // No tags yet.
return this.algorithm.getOrderedRooms();
}
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
public get matrixClient(): MatrixClient {
return this._matrixClient;
}
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove enabled flag with the old RoomListStore: https://github.com/vector-im/riot-web/issues/14231
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
private checkEnabled() {
this.enabled = SettingsStore.isFeatureEnabled("feature_new_room_list");
if (this.enabled) {
Update misc documentation and spell indices correctly
2020-05-14 22:01:51 +03:00
console.log("⚡ new room list store engaged");
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
}
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
private async readAndCacheSettingsFromStore() {
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
const tagsEnabled = SettingsStore.isFeatureEnabled("feature_custom_tags");
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
await this.updateState({
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
tagsEnabled,
});
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
await this.updateAlgorithmInstances();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
private onRVSUpdate = async (quiet = false) => {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
if (!this.enabled) return; // TODO: Remove with https://github.com/vector-im/riot-web/issues/14231
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
if (!this.matrixClient) return; // We assume there won't be RVS updates without a client
const activeRoomId = RoomViewStore.getRoomId();
if (!activeRoomId && this.algorithm.stickyRoom) {
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.algorithm.setStickyRoom(null);
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
} else if (activeRoomId) {
const activeRoom = this.matrixClient.getRoom(activeRoomId);
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
if (!activeRoom) {
console.warn(`${activeRoomId} is current in RVS but missing from client - clearing sticky room`);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.algorithm.setStickyRoom(null);
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
} else if (activeRoom !== this.algorithm.stickyRoom) {
Revert "Remove a bunch of noisy logging from the room list"
2020-07-03 17:54:54 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
console.log(`Changing sticky room to ${activeRoomId}`);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.algorithm.setStickyRoom(activeRoom);
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
}
}
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
if (!quiet) this.updateFn.trigger();
Introduce sticky rooms to the new room list Originally this was intended to be done only in the importance algorithm, however it is clear that all algorithms will need to deal with this. As such, it has been put into the base class to deal with as we may override it in the future. This commit should be self-documenting enough to describe what is going on, though the major highlight is that the handling of the sticky room is done by lying to the underlying algorithm. This has not been optimized for performance yet. For https://github.com/vector-im/riot-web/issues/13635
2020-06-06 03:44:05 +03:00
};
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
protected async onDispatch(payload: ActionPayload) {
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
if (payload.action === 'MatrixActions.sync') {
// Filter out anything that isn't the first PREPARED sync.
if (!(payload.prevState === 'PREPARED' && payload.state !== 'PREPARED')) {
return;
}
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove with https://github.com/vector-im/riot-web/issues/14231
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
this.checkEnabled();
if (!this.enabled) return;
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
this._matrixClient = payload.matrixClient;
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
// Update any settings here, as some may have happened before we were logically ready.
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
console.log("Regenerating room lists: Startup");
await this.readAndCacheSettingsFromStore();
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.regenerateAllLists(true);
await this.onRVSUpdate(true); // fake an RVS update to adjust sticky room, if needed
this.updateFn.trigger();
return; // no point in running the next conditions - they won't match
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
// TODO: Remove this once the RoomListStore becomes default
if (!this.enabled) return;
if (payload.action === 'on_client_not_viable' || payload.action === 'on_logged_out') {
// Reset state without causing updates as the client will have been destroyed
// and downstream code will throw NPE errors.
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.reset(null, true);
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
this._matrixClient = null;
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
this.initialListsGenerated = false; // we'll want to regenerate them
}
// Everything below here requires a MatrixClient or some sort of logical readiness.
const logicallyReady = this.matrixClient && this.initialListsGenerated;
if (!logicallyReady) return;
if (payload.action === 'setting_updated') {
if (this.watchedSettings.includes(payload.settingName)) {
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
console.log("Regenerating room lists: Settings changed");
await this.readAndCacheSettingsFromStore();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.regenerateAllLists(true); // regenerate the lists now
this.updateFn.trigger();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
Early handling of dispatched events A possible approach to handling the various triggers for recategorizing rooms.
2020-05-04 18:06:34 +03:00
}
if (!this.algorithm) {
// This shouldn't happen because `initialListsGenerated` implies we have an algorithm.
throw new Error("Room list store has no algorithm to process dispatcher update with");
}
if (payload.action === 'MatrixActions.Room.receipt') {
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
// First see if the receipt event is for our own user. If it was, trigger
// a room update (we probably read the room on a different device).
Update badge counts in new room list as needed
2020-05-26 00:54:02 +03:00
if (readReceiptChangeIsFor(payload.event, this.matrixClient)) {
Fix read receipt handling in the new room list Fixes https://github.com/vector-im/riot-web/issues/14064 Fixes https://github.com/vector-im/riot-web/issues/14082 Turns out the event doesn't reference a room, so we need to use the accompanied room reference instead.
2020-06-23 00:12:30 +03:00
const room = payload.room;
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
if (!room) {
Fix read receipt handling in the new room list Fixes https://github.com/vector-im/riot-web/issues/14064 Fixes https://github.com/vector-im/riot-web/issues/14082 Turns out the event doesn't reference a room, so we need to use the accompanied room reference instead.
2020-06-23 00:12:30 +03:00
console.warn(`Own read receipt was in unknown room ${room.roomId}`);
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
return;
}
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Fix read receipt handling in the new room list Fixes https://github.com/vector-im/riot-web/issues/14064 Fixes https://github.com/vector-im/riot-web/issues/14082 Turns out the event doesn't reference a room, so we need to use the accompanied room reference instead.
2020-06-23 00:12:30 +03:00
console.log(`[RoomListDebug] Got own read receipt in ${room.roomId}`);
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
await this.handleRoomUpdate(room, RoomUpdateCause.ReadReceipt);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Update badge counts in new room list as needed
2020-05-26 00:54:02 +03:00
return;
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
} else if (payload.action === 'MatrixActions.Room.tags') {
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
const roomPayload = (<any>payload); // TODO: Type out the dispatcher types
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
console.log(`[RoomListDebug] Got tag change in ${roomPayload.room.roomId}`);
await this.handleRoomUpdate(roomPayload.room, RoomUpdateCause.PossibleTagChange);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Early handling of dispatched events A possible approach to handling the various triggers for recategorizing rooms.
2020-05-04 18:06:34 +03:00
} else if (payload.action === 'MatrixActions.Room.timeline') {
const eventPayload = (<any>payload); // TODO: Type out the dispatcher types
// Ignore non-live events (backfill)
if (!eventPayload.isLiveEvent || !payload.isLiveUnfilteredRoomTimelineEvent) return;
const roomId = eventPayload.event.getRoomId();
const room = this.matrixClient.getRoom(roomId);
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
const tryUpdate = async (updatedRoom: Room) => {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Implement breadcrumb notifications and scrolling
2020-07-01 01:24:46 +03:00
console.log(`[RoomListDebug] Live timeline event ${eventPayload.event.getId()}` +
Fix indentation
2020-07-02 22:23:20 +03:00
` in ${updatedRoom.roomId}`);
Handle/hide old rooms in the room list Fixes https://github.com/vector-im/riot-web/issues/14003
2020-06-16 05:11:06 +03:00
if (eventPayload.event.getType() === 'm.room.tombstone' && eventPayload.event.getStateKey() === '') {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
console.log(`[RoomListDebug] Got tombstone event - trying to remove now-dead room`);
const newRoom = this.matrixClient.getRoom(eventPayload.event.getContent()['replacement_room']);
if (newRoom) {
// If we have the new room, then the new room check will have seen the predecessor
// and did the required updates, so do nothing here.
return;
}
Handle/hide old rooms in the room list Fixes https://github.com/vector-im/riot-web/issues/14003
2020-06-16 05:11:06 +03:00
}
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
await this.handleRoomUpdate(updatedRoom, RoomUpdateCause.Timeline);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
};
if (!room) {
console.warn(`Live timeline event ${eventPayload.event.getId()} received without associated room`);
console.warn(`Queuing failed room update for retry as a result.`);
setTimeout(async () => {
const updatedRoom = this.matrixClient.getRoom(roomId);
await tryUpdate(updatedRoom);
}, 100); // 100ms should be enough for the room to show up
return;
} else {
await tryUpdate(room);
}
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
} else if (payload.action === 'MatrixActions.Event.decrypted') {
Handle event decryption too
2020-05-08 20:59:03 +03:00
const eventPayload = (<any>payload); // TODO: Type out the dispatcher types
const roomId = eventPayload.event.getRoomId();
const room = this.matrixClient.getRoom(roomId);
if (!room) {
console.warn(`Event ${eventPayload.event.getId()} was decrypted in an unknown room ${roomId}`);
return;
}
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Handle event decryption too
2020-05-08 20:59:03 +03:00
console.log(`[RoomListDebug] Decrypted timeline event ${eventPayload.event.getId()} in ${roomId}`);
await this.handleRoomUpdate(room, RoomUpdateCause.Timeline);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
} else if (payload.action === 'MatrixActions.accountData' && payload.event_type === 'm.direct') {
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
const eventPayload = (<any>payload); // TODO: Type out the dispatcher types
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
console.log(`[RoomListDebug] Received updated DM map`);
const dmMap = eventPayload.event.getContent();
for (const userId of Object.keys(dmMap)) {
const roomIds = dmMap[userId];
for (const roomId of roomIds) {
const room = this.matrixClient.getRoom(roomId);
if (!room) {
console.warn(`${roomId} was found in DMs but the room is not in the store`);
continue;
}
// We expect this RoomUpdateCause to no-op if there's no change, and we don't expect
// the user to have hundreds of rooms to update in one event. As such, we just hammer
// away at updates until the problem is solved. If we were expecting more than a couple
// of rooms to be updated at once, we would consider batching the rooms up.
await this.handleRoomUpdate(room, RoomUpdateCause.PossibleTagChange);
}
}
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
} else if (payload.action === 'MatrixActions.Room.myMembership') {
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
const membershipPayload = (<any>payload); // TODO: Type out the dispatcher types
Handle room invites as new rooms We wouldn't have seen them before, so might as well treat them as new instead of tag changes.
2020-06-30 23:23:00 +03:00
const oldMembership = getEffectiveMembership(membershipPayload.oldMembership);
const newMembership = getEffectiveMembership(membershipPayload.membership);
if (oldMembership !== EffectiveMembership.Join && newMembership === EffectiveMembership.Join) {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
console.log(`[RoomListDebug] Handling new room ${membershipPayload.room.roomId}`);
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
// If we're joining an upgraded room, we'll want to make sure we don't proliferate
// the dead room in the list.
const createEvent = membershipPayload.room.currentState.getStateEvents("m.room.create", "");
if (createEvent && createEvent.getContent()['predecessor']) {
console.log(`[RoomListDebug] Room has a predecessor`);
const prevRoom = this.matrixClient.getRoom(createEvent.getContent()['predecessor']['room_id']);
if (prevRoom) {
const isSticky = this.algorithm.stickyRoom === prevRoom;
if (isSticky) {
console.log(`[RoomListDebug] Clearing sticky room due to room upgrade`);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
await this.algorithm.setStickyRoom(null);
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
}
// Note: we hit the algorithm instead of our handleRoomUpdate() function to
// avoid redundant updates.
console.log(`[RoomListDebug] Removing previous room from room list`);
await this.algorithm.handleRoomUpdate(prevRoom, RoomUpdateCause.RoomRemoved);
}
}
console.log(`[RoomListDebug] Adding new room to room list`);
await this.handleRoomUpdate(membershipPayload.room, RoomUpdateCause.NewRoom);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
return;
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
}
Handle room invites as new rooms We wouldn't have seen them before, so might as well treat them as new instead of tag changes.
2020-06-30 23:23:00 +03:00
if (oldMembership !== EffectiveMembership.Invite && newMembership === EffectiveMembership.Invite) {
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
console.log(`[RoomListDebug] Handling invite to ${membershipPayload.room.roomId}`);
await this.handleRoomUpdate(membershipPayload.room, RoomUpdateCause.NewRoom);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Handle room invites as new rooms We wouldn't have seen them before, so might as well treat them as new instead of tag changes.
2020-06-30 23:23:00 +03:00
return;
}
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
// If it's not a join, it's transitioning into a different list (possibly historical)
Handle room invites as new rooms We wouldn't have seen them before, so might as well treat them as new instead of tag changes.
2020-06-30 23:23:00 +03:00
if (oldMembership !== newMembership) {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
console.log(`[RoomListDebug] Handling membership change in ${membershipPayload.room.roomId}`);
Fix proliferation when joining upgraded rooms We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
2020-06-25 06:31:44 +03:00
await this.handleRoomUpdate(membershipPayload.room, RoomUpdateCause.PossibleTagChange);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Handle remaining cases for room updates in new room list For https://github.com/vector-im/riot-web/issues/13635 This adds support for: * Tag changes * DM changes * Marking our own rooms as read * Our own membership changes The remaining branch we didn't need was the alternate 'new room' branch, so it was removed. This is not optimized - optimization is deferred.
2020-06-06 05:12:32 +03:00
return;
}
Early handling of dispatched events A possible approach to handling the various triggers for recategorizing rooms.
2020-05-04 18:06:34 +03:00
}
}
private async handleRoomUpdate(room: Room, cause: RoomUpdateCause): Promise<any> {
const shouldUpdate = await this.algorithm.handleRoomUpdate(room, cause);
if (shouldUpdate) {
Revert "Remove a bunch of noisy logging from the room list"
2020-07-03 17:54:54 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
console.log(`[DEBUG] Room "${room.name}" (${room.roomId}) triggered by ${cause} requires list update`);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.mark();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
}
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
public async setTagSorting(tagId: TagID, sort: SortAlgorithm) {
await this.algorithm.setTagSorting(tagId, sort);
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Per-account? https://github.com/vector-im/riot-web/issues/14114
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
localStorage.setItem(`mx_tagSort_${tagId}`, sort);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.triggerIfWillMark();
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
}
public getTagSorting(tagId: TagID): SortAlgorithm {
return this.algorithm.getTagSorting(tagId);
}
// noinspection JSMethodCanBeStatic
private getStoredTagSorting(tagId: TagID): SortAlgorithm {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Per-account? https://github.com/vector-im/riot-web/issues/14114
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
return <SortAlgorithm>localStorage.getItem(`mx_tagSort_${tagId}`);
}
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
// logic must match calculateListOrder
private calculateTagSorting(tagId: TagID): SortAlgorithm {
const defaultSort = SortAlgorithm.Alphabetic;
const settingAlphabetical = SettingsStore.getValue("RoomList.orderAlphabetically", null, true);
const definedSort = this.getTagSorting(tagId);
const storedSort = this.getStoredTagSorting(tagId);
// We use the following order to determine which of the 4 flags to use:
// Stored > Settings > Defined > Default
let tagSort = defaultSort;
if (storedSort) {
tagSort = storedSort;
} else if (!isNullOrUndefined(settingAlphabetical)) {
tagSort = settingAlphabetical ? SortAlgorithm.Alphabetic : SortAlgorithm.Recent;
} else if (definedSort) {
tagSort = definedSort;
} // else default (already set)
return tagSort;
}
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
public async setListOrder(tagId: TagID, order: ListAlgorithm) {
await this.algorithm.setListOrdering(tagId, order);
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Per-account? https://github.com/vector-im/riot-web/issues/14114
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
localStorage.setItem(`mx_listOrder_${tagId}`, order);
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.triggerIfWillMark();
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
}
public getListOrder(tagId: TagID): ListAlgorithm {
return this.algorithm.getListOrdering(tagId);
}
// noinspection JSMethodCanBeStatic
private getStoredListOrder(tagId: TagID): ListAlgorithm {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Per-account? https://github.com/vector-im/riot-web/issues/14114
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
return <ListAlgorithm>localStorage.getItem(`mx_listOrder_${tagId}`);
}
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
// logic must match calculateTagSorting
private calculateListOrder(tagId: TagID): ListAlgorithm {
Disable use of account-level ordering options in new room list Fixes https://github.com/vector-im/riot-web/issues/14069 We can't drop them completely for compatibility with the old room list.
2020-07-01 04:31:59 +03:00
const defaultOrder = ListAlgorithm.Natural;
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
const settingImportance = SettingsStore.getValue("RoomList.orderByImportance", null, true);
const definedOrder = this.getListOrder(tagId);
const storedOrder = this.getStoredListOrder(tagId);
// We use the following order to determine which of the 4 flags to use:
// Stored > Settings > Defined > Default
let listOrder = defaultOrder;
if (storedOrder) {
listOrder = storedOrder;
} else if (!isNullOrUndefined(settingImportance)) {
listOrder = settingImportance ? ListAlgorithm.Importance : ListAlgorithm.Natural;
} else if (definedOrder) {
listOrder = definedOrder;
} // else default (already set)
return listOrder;
}
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
private async updateAlgorithmInstances() {
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
// We'll require an update, so mark for one. Marking now also prevents the calls
// to setTagSorting and setListOrder from causing triggers.
this.updateFn.mark();
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
for (const tag of Object.keys(this.orderedLists)) {
const definedSort = this.getTagSorting(tag);
const definedOrder = this.getListOrder(tag);
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
const tagSort = this.calculateTagSorting(tag);
const listOrder = this.calculateListOrder(tag);
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
if (tagSort !== definedSort) {
await this.setTagSorting(tag, tagSort);
}
if (listOrder !== definedOrder) {
await this.setListOrder(tag, listOrder);
}
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
}
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
protected async updateState(newState: IState) {
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
if (!this.enabled) return;
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
await super.updateState(newState);
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
private onAlgorithmListUpdated = () => {
Revert "Remove a bunch of noisy logging from the room list"
2020-07-03 17:54:54 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
console.log("Underlying algorithm has triggered a list update - marking");
this.updateFn.mark();
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
};
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
private async regenerateAllLists(quiet = false) {
Invent an AsyncStore and use it for room lists This is to get around the problem of a slow dispatch loop. Instead of slowing the whole app down to deal with room lists, we'll just raise events to say we're ready. Based upon the EventEmitter class.
2020-04-28 00:25:04 +03:00
console.warn("Regenerating all room lists");
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
const sorts: ITagSortingMap = {};
const orders: IListOrderingMap = {};
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
for (const tagId of OrderedDefaultTagIDs) {
Respect and fix understanding of legacy options Fixes https://github.com/vector-im/riot-web/issues/14372 We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
2020-07-07 23:45:08 +03:00
sorts[tagId] = this.calculateTagSorting(tagId);
orders[tagId] = this.calculateListOrder(tagId);
Move list layout management to its own store This is more general maintenance than performance as the RoomList doesn't need to be generating layouts for the sublists, and it certainly doesn't need to be creating a bunch of extra ones. The sublists are perfectly capable of getting their own layout instance and using it, and we are perfectly able to limit the number of these things we create through the session's lifespan.
2020-07-09 03:27:50 +03:00
RoomListLayoutStore.instance.ensureLayoutExists(tagId);
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
if (this.state.tagsEnabled) {
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Fix custom tags: https://github.com/vector-im/riot-web/issues/14091
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
const roomTags = TagOrderStore.getOrderedTags() || [];
Clean up TODO comments for new room list All relevant TODOs should still be present, and reference an issue for easy finding.
2020-06-29 05:03:04 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
console.log("rtags", roomTags);
}
Dumb down list algorithms in favour of smarter tags This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things. Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum. The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
2020-06-12 06:24:25 +03:00
await this.algorithm.populateTags(sorts, orders);
Handle/hide old rooms in the room list Fixes https://github.com/vector-im/riot-web/issues/14003
2020-06-16 05:11:06 +03:00
await this.algorithm.setKnownRooms(this.matrixClient.getVisibleRooms());
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
this.initialListsGenerated = true;
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
if (!quiet) this.updateFn.trigger();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
public addFilter(filter: IFilterCondition): void {
Revert "Remove a bunch of noisy logging from the room list"
2020-07-03 17:54:54 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
console.log("Adding filter condition:", filter);
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
this.filterConditions.push(filter);
if (this.algorithm) {
this.algorithm.addFilterCondition(filter);
}
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
}
public removeFilter(filter: IFilterCondition): void {
Revert "Remove a bunch of noisy logging from the room list"
2020-07-03 17:54:54 +03:00
// TODO: Remove debug: https://github.com/vector-im/riot-web/issues/14035
console.log("Removing filter condition:", filter);
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
const idx = this.filterConditions.indexOf(filter);
if (idx >= 0) {
this.filterConditions.splice(idx, 1);
if (this.algorithm) {
this.algorithm.removeFilterCondition(filter);
}
}
Dedupe room list store updates by marking for updates The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing. Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time. Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
2020-07-09 23:52:54 +03:00
this.updateFn.trigger();
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
}
Implement breadcrumb notifications and scrolling
2020-07-01 01:24:46 +03:00
/**
* Gets the tags for a room identified by the store. The returned set
* should never be empty, and will contain DefaultTagID.Untagged if
* the store is not aware of any tags.
* @param room The room to get the tags for.
* @returns The tags for the room.
*/
public getTagsForRoom(room: Room): TagID[] {
const algorithmTags = this.algorithm.getTagsForRoom(room);
if (!algorithmTags) return [DefaultTagID.Untagged];
return algorithmTags;
}
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
export default class RoomListStore {
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
private static internalInstance: RoomListStore2;
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
public static get instance(): RoomListStore2 {
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
if (!RoomListStore.internalInstance) {
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
RoomListStore.internalInstance = new RoomListStore2();
Initial breakout for room list rewrite This does a number of things (sorry): * Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593) * Sets up the stack for a whole new room list store, and later components for usage. * Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled * Demonstrates a possible structure for algorithms
2020-03-20 23:38:20 +03:00
}
return RoomListStore.internalInstance;
}
}
Add initial filtering support to new room list For https://github.com/vector-im/riot-web/issues/13635 This is an incomplete implementation and is mostly dumped in this state for review purposes. The remainder of the features/bugs are expected to be in more bite-sized chunks. This exposes the RoomListStore on the window for easy access to things like the new filter functions (used in debugging). This also adds initial handling of "new rooms" to the client, though the support is poor. Known bugs: * [ ] Regenerates the entire room list when a new room is seen. * [ ] Doesn't handle 2+ filters at the same time very well (see gif. will need a priority/ordering of some sort). * [ ] Doesn't handle room order changes within a tag yet, despite the docs implying it does.
2020-05-29 16:59:06 +03:00
window.mx_RoomListStore2 = RoomListStore.instance;
Reference in a new issue Copy permalink