Repository navigation
Replies: 4 comments 4 replies
|
Maybe there should just be some kind of Edit: I guess making Show in particular concurrent doesn't make too much sense. |
|
What is the difference between this and just having detached nodes still live? I understood Transitions because well we need to stop from apply certain changes until we reach async consistency. This feels a bit like just keeping stuff around.. is it inert? Because we could just maintain 2 roots and only attach one and call it a day in the simple case. |
|
re: naming. I immediately thought this was going to be some sort of interface for using an offscreen canvas: https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas Do I have a better naming suggestion however? Nope. |
|
What's the main improvement over |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
<Offscreen>is a component that allows switching between two branched UIs.<Show>allows switching between two UI states however both possible states aren't branched/concurrently-rendered nor do they have concurrent lifecycles.<Suspense>allows branched rendering but the lifecycle is only retained for the main UI and not the fallback UI.<Offscreen>is the cross between<Show>and<Suspense>such that a condition can control with UI can be shown, while also rendering both UIs concurrently. Unlike<Suspense>,<Offscreen>can retain the lifecycle of the hidden UI, making the two possible UI states "equal".Ideal use case for
<Offscreen>includes Disclosure, Modal, Dropdown and Tab components where the hidden UI can retain their lifecycles while being hidden.Issues:
<Offscreen>support more than two UI slots?Theoretical examples:
Possible better name?
All reactions