Re: [w3ctag/design-reviews] Shared Element Transitions API (Issue #748)

This is great feedback. What day & time are folks likely to look at this? As in, assuming I'm not working the weekend (which I plan not to), how long do I have to bash the explainer into shape?

> It would be nice if there was a way to use SET without the extensive refactoring of having to put the DOM manipulation code in the `transition.prepare()` callback, but something that is easier to make work with feature detection too (e.g. some way to signal the start and end of the transition, while DOM manipulation code remains where it was?)

The browser needs to capture the 'before' state, which is async. But yeah:

```js
const transition = new SameDocumentTransition();
await transition.prepare(async () => {
  await updateTheDOMSomehow();
});
```

…could have an alternative API like:

```js
const transition = new SameDocumentTransition();
await transition.captureBeforeState();
await updateTheDOMSomehow();
transition.domChanged();
```

The main difference between the two is if `updateTheDOMSomehow` throws. Then, `domChanged` won't be called, and now rendering is frozen until some kind of timeout.

With the callback model, it's more likely that we catch the error, and know to abandon the transition. [WebLocks](https://w3c.github.io/web-locks/#api-lock-manager) use a similar pattern for this reason.

> As an author, I wouldn't even know how to use `transition.prepare()` when using a framework that does the DOM manipulation for me.

Depends on the framework. I created a React hook to do it, and it's what https://http203-playlist.netlify.app/ uses. React has `useLayoutEffect` for hearing about DOM changes before the next render.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/748#issuecomment-1220846412

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/748/1220846412@github.com>