Global view transitions for history restore

[davidwilde]

Description

I added ViewTransitions to the restoreHistory function. In this pull request I only made this change when the user has enabled htmx.config.globalViewTransitions. This is as a PR for opening a discussion on this as anything else as I have some questions to the best approach for this work.

Screen.Recording.2024-09-06.at.12.05.21.mov

I understand that because this not a either a bugfix, a documentation update, or a new feature that has been explicitly approved via an issue. I apologise as I only saw those particular guideline

Questions

1. Should this have its own config flag to enable this behavior? Potentially this is breaking expectations by adding this to navigating history. Is adding this under globalViewTransitions sensible here? Maybe a config flag like htmx.config.historyViewTransitions?
2. Should a htmx:beforeTransition event be thrown?

Idea

During development of this I had an idea but I thought it would be too big a PR and I wanted to start this initial discussion first, but I considered that it could be possible to add a transition flag into the history. This would be caught from the hx-swap of each request and mean that requests which updated the history, would also be able to play back the transition even without globalViewTransitions needing to be set (but then htmx.config.historyViewTransitions would make more sense)

Corresponding issue:

#1703

Testing

I tested this manually, switching on and off the htmx.config.globalViewTransitions flag. I ran the test suite locally and the linting rules

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for
  source changes)
• This is either a bugfix, a documentation update, or a new feature that has been explicitly
  approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded

[pokonski]

This would be great to have as currently navigating back is jarring compared to navigating forward

Should this have its own config flag to enable this behavior?

Not a decision maker but I guess that's the safest way to not change the behaviour for current users