* Add non-consent (default) Synapse template
* Add consent test
* Add create room test
* Stash work
* Initial threads tests
* fix
* Delete old threads e2e tests, plan new ones
* Fix typed s'more
* Try something else
* specify d.ts
* Fix types once and for all?
* Fix the consent tests
* Iterate threads test harness
* Fix dispatcher types
* Iterate threads test
* fix typing
* Alternative import attempt
* let it break let it break let it break
* Tweak types
* Stash
* delint and update docs
* null-guard scrollIntoView
* Iterate threads test
* Apply suggestions from code review
* Initial doc for cypress tests
* Too many documents
* Typo
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Add example
* Typo
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Document and support the established naming convention for config opts
This change:
* Rename `ConfigOptions` to `IConfigOptions` to match code convention/style, plus move it to a dedicated file
* Update comments and surrounding documentation
* Define every single documented option (from element-web's config.md)
* Enable a linter to enforce the convention
* Invent a translation layer for a different change to use
* No attempt to fix build errors from doing this (at this stage)
* Add demo of lint rule in action
* Fix all obvious instances of SdkConfig case conflicts
* Fix tests to use SdkConfig directly
* Add docs to make unset() calling safer
* Appease the linter
* Update documentation to match snake_case_config
* Fix more instances of square brackets off SdkConfig
Fixes https://github.com/vector-im/element-web/issues/16799
This change replaces the "relative priority" system for filters with a kind model. The kind is used to differentiate and optimize when/where a filter condition is applied, resulting in a more stable ordering of the room list. The included documentation describes what this means in detail.
This also introduces a way to inhibit updates being emitted from the Algorithm class given what we're doing to the poor thing will cause it to do a bunch of recalculation. Inhibiting the update and implicitly applying it (as part of our updateFn.mark()/trigger steps) results in much better performance.
This has been tested on my own account with both communities and spaces of varying complexity: it feels faster, though the measurements appear to be within an error tolerance of each other (read: there's no performance impact of this).
Fixes https://github.com/vector-im/riot-web/issues/8936
Watchers are now managed by the SettingsStore itself through a global/default watch manager. As per the included documentation, the watch manager dispatches updates to callbacks which are redirected by the SettingsStore for consumer safety.
This implements a dream of one day being able to listen for changes in a settings to react to them, regardless of which device actually changed the setting. The use case for this kind of thing is extremely limited, but when it is needed it should be more than powerful enough.
