From af443c4cff2e78388ca1c28922d7b0833f5f880c Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 2 Apr 2021 19:33:16 -0600 Subject: [PATCH] Update docs/room-list-store.md Co-authored-by: J. Ryan Stinnett --- docs/room-list-store.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/room-list-store.md b/docs/room-list-store.md index f6330f5722..6fc5f71124 100644 --- a/docs/room-list-store.md +++ b/docs/room-list-store.md @@ -145,7 +145,7 @@ expect a change in the condition unless the condition says it has changed. This maintain the caching behaviour described above. One might ask why we don't just use prefilter conditions for everything, and the answer is one of slight -subtly: in the cases of prefilters we are knowingly exposing the user to a workspace-style UX where +subtlety: in the cases of prefilters we are knowingly exposing the user to a workspace-style UX where room notifications are self-contained within that workspace. Runtime filters tend to not want to affect visible notification counts (as it doesn't want the room header to suddenly be confusing to the user as they type), and occasionally UX like "found 2/12 rooms" is desirable. If prefiltering were used instead,