CacheStorage (2/3) #569
CacheStorage (2/3) #569
Conversation
maxg-square
force-pushed
the
maxg/cache_2_envcache
branch
from
5d53aa4 to
84fe9bb
Compare
* maxg/cache_1_equivalency: Release 6.3.0 Assert in debug mode when large content viewer is not placed inside an interaction container Expose largeContentViewerInteraction on LargeContentViewer backing view via protocol Stopped installing xcodes in GitHub Actions file chore: Release 6.2.0 Support accessibility large content viewer
watt
left a comment
watt
left a comment
There was a problem hiding this comment.
Got a few questions on this one before I can stamp it.
| extension Environment { | ||
|
|
||
| struct CacheStorageEnvironmentKey: InternalEnvironmentKey { | ||
| static var defaultValue = CacheStorage() |
There was a problem hiding this comment.
I'm not convinced this a safe way to control the lifetime or the bounds of this cache. Environment's not tied to the lifetime of a single BlueprintView.
Why not attach this to something else in the render tree, like LayoutTreeNode? Environment is a lot easier to reason about when it's only used for simple values.
There was a problem hiding this comment.
After chatting about this and getting a better understanding of the scope, this makes more sense to me here. Another question: can we avoid the need for "internal" keys by giving the CacheStorage equality on the reference? Then it'll be trivially equatable within the same hosting view.
| import Foundation | ||
|
|
||
| /// Validating cache is a cache which, if it has a value for a key, runs a closure to verify that the cache value is still relevant and not state. | ||
| /// This is useful for cases when you might otherwise wish to store the validation data as a key, but it does not conform to Hashable, or its hashability properties do not neccessarily affect the validity of the cached data. |
There was a problem hiding this comment.
It took me a while to understand what you mean, but if I've got it right, what you want is a cache that invalidates entries lazily on retrieval rather than eagerly when the validation data changes. Is that accurate?
* maxg/cache_1_equivalency: chore: Release 6.5.0 (#600) refactor: Migrate Accessibility Infrastructure from Market Design System (#593) chore: Release 6.4.0 (#599) Adding safe area edge detection for the scrollableAxes behavior (#596) Reverting the change to remove accessibility traits on the AttributedLabel (#597) Update changelog for 6.3.1 release (#591) Fix warnings in Xcode 26 (#589) Apply empty accessibility traits to AttributedLabel if supplied traits is nil Bump rexml from 3.3.9 to 3.4.2
2/3 for caching changes.
Big-picture PR here: #587
Design doc: https://docs.google.com/document/d/1CLhFbzZGbEKgvZTUwLuGbFY-rfZNJVTi6f3PkoZT9qI/edit?usp=sharing
HostingViewContext, an object which hangs off ofEnvironment.HostingViewContexthas a similar API toEnvironment, with consumers declaring their types and default values by declaring aCrossLayoutCacheKey.Environmentwhich do not participate inContextuallyEquivalentchecks.EnvironmentAccessList, which is a snapshot of anEnvironmentthat holds a subset of its storage, and is used byValidatingCache.ValidatingCache, which allows a key to be set with a value that's associated with a validation function.EnvironmentValidatingCacheandEnvironmentAndValueValidatingCache, which are simplified interfaces toValidatingCachewhich provide additional comparison ofEnvironmentcontexts.