Re: [csswg-drafts] [css-view-transitions-2] Dealing with promises on old VT object (#9888)

> This is a tricky one that could use author feedback

I would need to get my hands on a prototype to be sure but my gut feeling tells me none of the promises make sense at all. IUC the vt object you receive inside `pageconceal` still incomplete. Only after the logic inside that handler has been executed, the viewTransition will actually start.

Looking at existing code that I use in an SPA+VT, looking to see see what I could carry over to MPA/`pageconceal`, I would only carry over the stuff that happens before `document.startViewTransition()` ever gets called. The stuff after `document.startViewTransition()` would be used on the new page.

- SPA:
    
    ```js
    navigation.addEventListener("navigate", (e) => {
      // … If VT MPA Support: return

      e.intercept({
        handler: async () => {
          // … Determine transition type
          
          // … Give some elements a v-t-name if needed
        
          // Create and start VT
          const t = document.startViewTransition({
            update,
            type,
          });
          
          await t.updateCallbackDone;
          // … Analytics, or whatever
          
          await t.finished;
          // … Cleanup
        },
    });
    ```

-  MPA (old page):

    ```js
    document.addEventListener(`pageconceal`, (e) => {
      // … Determine transition type
    
      // … Give some elements a v-t-name
    });
    ```

In the MPA code I would only need to determine the VT type to use (or maybe skip the transition) and have no need for any of the promises.

Maybe it makes sense to expose something like a `PendingViewTransition` instance in `pageconceal` to make it easily distinguishable for authors? You can’t really do anything with, besides changing some properties or skipping it. It would also have no promises at all. I think that is what is meant with option 2?

This `PendingViewTransition` instance would then be converted to a full `ViewTransition` instance on the new page, which an author gets passed into the `pagereveal` event.

> The old Document will have an event when the navigation is **about to be committed** but before the browser renders/caches the last frame.

Hmm. How would authors then easily get to know what the target URL is in order to determine the transition type? In the SPA, when intercepting the navigation, the navigation is already committed and the `navigation.currentEntry` updated. But here in `pageconceal` it is not.

It would be handy if the navigation already was committed, so that authors can then reuse their SPA code: read `navigation.currentEntry`, knowing that it’s the up-to-date destination URL. With it not being committed yet, authors would need to keep track of `destination` in the `navigate` event, store it in a variable, and then have `pageconceal` use that variable.

-- 
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9888#issuecomment-1930801630 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 February 2024 21:44:33 UTC