Add support for different view transition animations for the default transition type

[felixarntz]

Summary

See #1997

Relevant technical choices

• Adds new default-animation argument (and optional default-animation-args argument) to the view-transitions theme support arguments.
• Adds a view transition animation class and corresponding registry to handle view transition animations. Each view transition animation consists of:
  • A unique slug
  • CSS to be loaded
  • Whether the global view transition names should be applied for this animation
  • Whether the post-specific view transition names should be applied for this animation
  • Optional arguments for fine tuning (e.g. exact angle from which a wipe animation occurs)
  • Optional aliases (can also be used as a "short hand" for certain common argument values; e.g. "wipe-from-bottom" is an alias for the general "wipe", but as indicated will then configure the angle so that the wipe comes from the bottom of the screen)
• By default, the follow animations are available: fade (default), slide, swipe, wipe.

As with the other changes, all of this code was already implemented before in WordPress/wordpress-develop#8370. See WordPress/wordpress-develop#8370 (comment) for additional information on the available animations (ignore the points on the other transition types than default for now).

To test this locally, you can either add theme support with the arguments in your current theme, or temporarily alter the default that the plugin adds by itself. Make sure to run npm run build:plugin:view-transitions first, to ensure the built CSS and JavaScript is available.

A follow up PR will add a settings UI to change this default transition animation, to make it easy to modify for end users of the plugin, without touching code.

[codecov]

Codecov Report

Attention: Patch coverage is 64.23077% with 93 lines in your changes missing coverage. Please review.

Project coverage is 72.18%. Comparing base (b0310ee) to head (05cb442).
Report is 20 commits behind head on trunk.

Files with missing lines	Patch %	Lines
plugins/view-transitions/includes/theme.php	71.42%	40 Missing ⚠️
.../class-plvt-view-transition-animation-registry.php	41.66%	28 Missing ⚠️
.../includes/class-plvt-view-transition-animation.php	65.27%	25 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk    #2016      +/-   ##
==========================================
- Coverage   72.50%   72.18%   -0.32%     
==========================================
  Files          88       90       +2     
  Lines        7146     7399     +253     
==========================================
+ Hits         5181     5341     +160     
- Misses       1965     2058      +93     

Flag	Coverage Δ
multisite	72.18% <64.23%> (-0.32%)	⬇️
single	40.93% <64.23%> (+0.78%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: felixarntz <flixos90@git.wordpress.org>
Co-authored-by: mukeshpanchal27 <mukesh27@git.wordpress.org>
Co-authored-by: b1ink0 <b1ink0@git.wordpress.org>
Co-authored-by: ShyamGadde <shyamgadde@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[mukeshpanchal27]

Thanks for the PR. Overall, it looks solid to me. I've left a few nonblocking feedbacks, but I'm pre-approving it.

[b1ink0]

Do we plan to open this class to developers? If so, it currently has a hardcoded asset path that points to the current feature plugin directory. Does it make sense to add a stylesheet_path to extract its contents? However, the developer could also just add this logic to the get_stylesheet_callback. I was just thinking of abstracting the file_get_contents logic from the developer.

[felixarntz]

Great idea! I think the most intuitive solution for ease of use and flexibility would be to overload the use_stylesheet argument to optionally be a path string. Will update.

[b1ink0]

I think it could be renamed to just stylesheet and set to null by default in that case, as use_stylesheet makes it sound like a condition.

[felixarntz]

I'm not sure yet. Right now, all the internal usage does use it like a condition. Naming it stylesheet with a value of null suggests to me that it would require a string, but it also supports a boolean.

I don't think there's a clear right or wrong answer here, I'd prefer to stick to use_stylesheet for now since that's more in line with how the argument is used in the plugin so far.

[felixarntz]

Fixed in 0ebe9da

[b1ink0]

I think we should remove the hardcoded path completely to make it more explicit. Passing plvt_get_asset_path( "css/view-transition-animation-slug.css" ) while registering the animation would be better. This could also mean the use_stylesheet type could become false|string.

performance/plugins/view-transitions/includes/theme.php

Lines 141 to 150 in 05cb442

	$animation_registry->register_animation(
	'slide',
	array(
	'aliases' => array(
	'slide-from-right',
	'slide-from-bottom',
	'slide-from-left',
	'slide-from-top',
	),
	'use_stylesheet' => true,

Like this:

'use_stylesheet'              => plvt_get_asset_path( 'css/view-transition-animation-slug.css' ), 

[felixarntz]

I would say let's re-evaluate this separately. I think for now the current approach works well because:

• It makes it easy to use it with the plugin's own animations (by not requiring specification of a redundant path because within the plugin the path is predictable).
• It makes it flexible by allowing to specify the path for external animation registrations.

If we required the path, it would make the first point more difficult, so I'm not sure that's a good idea. We can discuss this further in a separate issue and consider changing in the future. Since it's an experimental feature plugin, we'll still be able to change this at any time.

[b1ink0]

Okay, thanks, this makes sense. I was just thinking along the lines of this eventually being merged into core, so we should avoid hardcoding. But as you said, we can change this at any time, so no issue.