[RFC] A first-class API for View Transitions

[nmn]

View Transitions are awesome. However, large parts of how they work depend on global style rules and unique identifiers which makes them a bad fit for an atomic styling system like StyleX.

However, with the addition of view-transition-class, which is now well supported in both Chrome and Safari (Firefox doesn't have any view transition support at all so far), there is now an opportunity to add a first class API that actually makes sense in StyleX.

The proposal

We could introduce a new stylex.viewTransitionClass API that works similarly to how stylex.keyframes works.

const slideIn = stylex.keyframes({
  '0%': { translateX: '100%' }
});
const slideOut = stylex.keyframes({
  '100%': { translateX: '-100%' }
});
const slide = stylex.viewTransitionClass({
  group: {
    transitionProperty: 'none',
  },
  imagePair: {
    borderRadius: 16,
  },
  old: {
    animationName: slideOut,
    animationDuration: '0.5s',
    animationTimingFunction: 'ease-out',
    animationFillMode: 'both',
  },
  new: {
    animationName: slideIn,
    animationDuration: '0.5s',
    animationTimingFunction: 'ease-out',
    animationFillMode: 'both',
  },
});

const styles = stylex.create({
  dialogPage: {
    viewTransitionClass: slide,
  }
});

Details

stylex.viewTransitionClass would take an object that can have the following keys:

• group as an equivalent to ::view-transition-group(*.theGeneratedClass)
• imagePair as an equivalent to ::view-transition-image-pair(*.theGeneratedClass)
• old as an equivalent to ::view-transition-old(*.theGeneratedClass)
• new as an equivalent to ::view-transition-new(*.theGeneratedClass)

All four keys would be optional, however, similar to stylex.keyframes generating a className with no styles would be a no-op.

The function would return a string which would be a generated className that can be used as the value of viewTransitionClass.

All of the other rules from stylex.keyframes would apply:

1. You can use stylex.viewTransitionClass in the same file a separate const declaration or inline within the stylex.create call itself
2. It cannot be imported from a separate file, but you should be able to define it within a stylex.defineVars (or stylex.defineConsts) call to be able to import it from another file.
3. It will generate a single "bag of styles" for the generated view transition class, similar to how stylex.keyframes generates a single @keyframes rule.

What about view-transition-name

It is hard offer any special API for view-transition-name as it needs to be globally unique by design. It needs be a dynamic style to be usable, so it's probably best used as a dynamic style:

const styles = stylex.create({
  viewTransitionName: (name) => ({viewTransitionName: name}),
});

(I'm writing another RFC with the idea of offering every CSS property as a pre-defined API for "inline" styles)

However, with the existence of view-transition-class we can recommend not using names to apply custom styles to view transitions at all.

Names, like IDs, can be used for element identity. view-transition-class can be used for applying all custom styles.

Should the styles be atomic

Since view-transition-class supports multiple space-separated classes, it is possible to generate atomic CSS rules for stylex.viewTransitionClass where each style property within would generate an individual class. All of this can be done with no change to the API at all.

However, I think it makes more sense to generate a single className for such scenarios. I'm making the assumption that there would only be a handful of "classes" needed in any particular app but that each class could have a large number of styles each, and that atomic styles for this use-case would result in an overall larger CSS file.

In either case, we can try either implementation first and then change our mind later if we want to.

Any other additions?

We should probably start with something minimal and expand later if the need presents itself.
One possibility I could see is adding an additional both key to allow adding styles that would apply to both old and new as a way to reduce verbosity. However, I think we should try omitting it at first as we can always use JS object spread to share common styles instead:

const both = {
  animationDuration: '0.5s',
  animationTimingFunction: 'ease-out',
  animationFillMode: 'both',
};
const slide = stylex.viewTransitionClass({
  old: {
    ...both,
    animationName: slideOut,
  },
  new: {
    ...both,
    animationName: slideIn,
  },
});

Fewer, composable APIs are better IMO.

Anything else?

This is all a relatively fresh idea, so I may have missed something important, but so far it feels like a relatively simply and straightforward addition that should make view transitions a lot more convenient in StyleX.

[nmn]

ping @mellyeliu @necolas for feedback

[necolas]

viewTransitionClass isn't a CSS property. Did you mean viewTransitionName?