You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Developers should be able to mark certain parent fields that are likely to be null or certain child fields that are expensive with e.g. directives or pipes or something in isograph literals. Examples:
The behavior in the above situation is as follows. The BestFriendDisplay and WorstEnemyVideoPlayer reader ASTs are lazily loaded (i.e. () => import(...)), i.e. not hard required in the User.DetailComponent reader AST.
Instead, the normalization artifact will have the reader ASTs we must load when we encounter a non-null best_friend/worst_enemy. Upon receiving data that makes these fields non-null, we start a network request for these readers. When complete, we write the resulting BestFriendDisplay (etc) into the store into a field that never gets GC'ed (probably).
The readers will suspend if they encounter a not-yet-loaded BestFriendDisplay etc
Readers should also be able to fall back to loading this. At minimum, readers need to also keep track of the nested components that are lazily dependent.
When we modify data in the store, we run through each subscription and get encountered records. When we re-read those fragments, we also check and potentially run the function to import.
Special __asConcreteType fields that refine to a concrete type should also be valid parents, in which case the above works iff the parent object exists and has the right type. So, we get Relay 3D.
The text was updated successfully, but these errors were encountered:
rbalicki2
changed the title
[Epic] Load reader ASTs if a non-null parent object is encountered
[Epic] Load reader ASTs only when a non-null parent object is encountered
Apr 21, 2024
BestFriendDisplay
andWorstEnemyVideoPlayer
reader ASTs are lazily loaded (i.e.() => import(...)
), i.e. not hard required in theUser.DetailComponent
reader AST.best_friend
/worst_enemy
. Upon receiving data that makes these fields non-null, we start a network request for these readers. When complete, we write the resultingBestFriendDisplay
(etc) into the store into a field that never gets GC'ed (probably).BestFriendDisplay
etc__asConcreteType
fields that refine to a concrete type should also be valid parents, in which case the above works iff the parent object exists and has the right type. So, we get Relay 3D.The text was updated successfully, but these errors were encountered: