Add createViewTransition function

[wuz]

View transitions are starting to get more support and it would be nice to use the same API style from createContainer to create locally scoped view transition names.

This PR adds a createViewContainer function with a name arg and an optional debugId arg.

Definitely open to suggestions on naming here - similar to CSS container queries, View Transitions have a view-transition-name css property and I thought it would track better with createContainer -> container-name to have createViewTransition -> view-transition-name.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e8117c9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[wuz]

@askoufis not sure if you are the right person to ping here, but I'd love to contribute to this project. This PR was based on some work I've been doing and I'd love to get it merged. If there are other ways I can help out, I'm more than happy to do so as well! We're using vanilla-extract heavily and I'd love to help grow the project.

Thanks!

[askoufis]

Sorry for the delay @wuz. I'm happy to help get this through, though there's no API for actually writing a @view-transition rule just yet.

@view-transition rules are also a bit different to other existing rules in that they can be nested within media queries, but aren't related to any classnames. I might try make a POC for a viewTransition API, and maybe that can be released alongside this API eventually.

[askoufis]

@wuz I also can't run CI on your fork, you might have some restrictive permissions enabled.

[wuz]

@askoufis Sorry, was out of office all week last week! Looking at this now! Let me see what's going on with the CI stuff, not sure what the permissions would be.

Edit: Okay, I think I figured out the actions thing - it should work now?

[wuz]

Thinking about this a bit, the API could look something like this:

import { globalViewTransition, createViewTransition, createViewTransitionGroup } from '@vanilla-extract/css';

// assuming keyframes called fadeOut and fadeIn defined somewhere

globalViewTransition({
  navigation: 'auto',
});

const fade = createViewTransition({
  old: {
    animationName: fadeOut,
  },
  new: {
    animationName: fadeIn,
  },
});

createViewTransitionGroup(fade, {
  animationDuration: "0.25s",
  animationTimingFunction: "ease",
});

becomes:

  @view-transition {
    navigation: auto;
  }

  ::view-transition-old(viewTransition_fade__jxjrfl) {
    animation-name: fadeOut;
  }

  ::view-transition-new(viewTransition_fade__jxjrfl) {
    animation-name: fadeIn;
  }

  ::view-transition-group(viewTransition_fade__jxjrfl) {
    animation-duration: 0.25s;
    animation-timing-function: ease;
  }
*/

[askoufis]

I'm unsure if we'd expose APIs like createViewTransition or createViewTransitionGroup as they're quite simple wrappers over some globalStyle calls. I'd leave that to the user to implement unless there's some nuance around view transition selectors that would necessitate VE handling CSS generation (though I don't think is the case).

For defining the @ rule, we could just name the function viewTransition as this aligns with other top-level @ rule APIs like layer and keyframes.

[askoufis]

This should be almost identical to createContainer.

Suggested change

	createViewTransition: {
	maxParams: 2,
	hasDebugId: ({ arguments: args }) => {
	const previousArg = args[args.length - 1];
	return t.isStringLiteral(previousArg) || t.isTemplateLiteral(previousArg);
	},
	},
	createViewTransition: {
	maxParams: 1,
	},