-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
model: Track/memoize stream-color variants somewhere other than /api/model
#393
Comments
What if we made one simple global cache, as a When UI code is processing a subscription with It's possible for that entry to fall into disuse at some point during the app session; for example, if
But I don't see really significant downsides to that. |
Those leaks should be basically fine in practice, since those changes aren't common and since this cache wouldn't outlast the current process. Still, it'd be nicer to have something that doesn't leak. How about just indexing on the stream ID? (As part of the If the user has lots of subscriptions sharing the same color, then that'd give up opportunities to reuse the results. But that's probably not common, and in any event the worst case is just one |
It would be nice for UI elements to consume these color swatches via In principle we should be able to instantiate per-account …Hmm. I guess one concrete downside of putting an |
If the cache were indexed by |
Yeah, I'd prefer to avoid having The global cache indexed by |
This will help verify the upcoming refactor, zulip#393 (storing stream-color variants in DesignVariables instead of Subscription model objects).
Just like we did for the InboxPage tests, in the previous commit. Here, there's one test that failed on the assumption that a particular icon was the only one in view; it apparently isn't anymore (probably because of the page's back button), and that assumption isn't important to the goal of the test. So, we adapt by removing that assumption. Related: zulip#393
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
This will help verify the upcoming refactor, zulip#393 (storing stream-color variants in DesignVariables instead of Subscription model objects).
Just like we did for the InboxPage tests, in the previous commit. Here, there's one test that failed on the assumption that a particular icon was the only one in view; it apparently isn't anymore (probably because of the page's back button), and that assumption isn't important to the goal of the test. So, we adapt by removing that assumption. Related: zulip#393
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
This will help verify the upcoming refactor, zulip#393 (storing stream-color variants in DesignVariables instead of Subscription model objects).
Just like we did for the InboxPage tests, in the previous commit. Here, there's one test that failed on the assumption that a particular icon was the only one in view; it apparently isn't anymore (probably because of the page's back button), and that assumption isn't important to the goal of the test. So, we adapt by removing that assumption. Related: zulip#393
Instead of putting them in Subscription model objects. This helps toward zulip#95 by bundling this with our other ThemeExtensions that will switch together between light and dark variants when the theme changes. It's also just nicer to separate this very UI-focused code out of api/model/ (zulip#393). Not marking [nfc] just because of differences in caching logic, although I don't expect a user-visible perf effect. Related: zulip#95 Fixes: zulip#393
This will help verify the upcoming refactor, zulip#393 (storing stream-color variants in DesignVariables instead of Subscription model objects).
Just like we did for the InboxPage tests, in the previous commit. Here, there's one test that failed on the assumption that a particular icon was the only one in view; it apparently isn't anymore (probably because of the page's back button), and that assumption isn't important to the goal of the test. So, we adapt by removing that assumption. Related: zulip#393
Currently (well, after #381), the
Subscription
class has acolorSwatch
method to return a memoizedStreamColorSwatch
. That code is in/api/model
.Probably there's a better, more UI-focused place to do those computations (adjusting lightness, opacity, etc.) and provide them to consumers: #381 (comment)
The text was updated successfully, but these errors were encountered: