Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

I am more curious about what would be the use cases behind it. This to me feels like quite some code added for features that most of ppl don't need. And also be able to work around with a custom inject/provide etc.

Other than that, I also feel the current design is a bit implicit, where the ref gets the child, not the component feels a bit counter-intuitive. This also makes it harder to keep type safety.

I was planning to try another approach.
Maybe should we do something done by vue core here ? Do you think This can be possible ?
This feature will indeed not be used by most of ppl 🤷‍♂️ , but I think those who wants to use it are expecting to be able to have an acess to refs.
edit: btw if you think we should'nt do it, let's just add a warning within the docs

I would first challenge the real-world use case of the original request, and see if there are better solutions to achieve what they need (maybe no need to mess with the ref) before discussing the design of API etc.

@antfu In essence it's about having more control when make page transitions, whether that would access (animation) tweens, dom elements which or page components. More specially, "control" in terms of a page transition might entail more than solely animating/manipulating the page el. In Nuxt 2 it was possible to do this by accessing the page through a ref via the parent for example. In the documentation there was no mention of this feature being deprecated for Nuxt 3.

edit: I wanted to add a note about "most of ppl don't need". Nuxt is quite popular in the creative development realm of coding (link for reference)

Hey @danielroe @antfu, what information do you need specifically to progress this?

Does an example in Nuxt 2 help? This way you can see the use case in a demo instead of text

Does an example in Nuxt 2 help? This way you can see the use case in a demo instead of text

That would be great ❤️

I think I understand the intention, but the current approach is a bit hacky to me. I guess for this, maybe we could have something built-in to support onBeforeEnter hooks in definePageMeta and compile away at build time.

Cool! I'll make a demo asap just to be sure the use case is clear

Hey @danielroe and @antfu, I've made a quick example. It basically contains two concepts:

1. Accessing a component which is (almost) always visible on a page. In this case it's the Navigation component. In the example the timeline tween gets triggered exactly when leaving a page. Reason being that visually it looks cohesive. It's possible to trigger the animation with a $route watcher in this case. However, it visually will happen after the page is shown.
2. Looking at some data from the page component or its child component. In this case I've kept in simple. Based on if the home page timeline tween has progressed past a certain point you either reverse the timeline tween or you pause it and make a simpler tween. In more complex situations you might have a staggered animation of letters from -100% to 0%. If the animation has progress to something like .95, it might be more visually appealing to create a new staggered animation which goes to 100% then to reverse the existing/original staggered animation

Even though I've added two concepts, it's not exhaustive. Another concept/example might be accessing data from an 3DPool (when working with WebGL) and manipulating/animating those before arriving at a new route or finishing the route navigation

Hey @danielroe and @antfu, I wanted check in to see if you have everything you need from me for this and if I can help out in some way

Hi @antfu & @danielroe, is there an update on this?

Pushed an implementation. Let me know what you think and feel free to update/amend.

/trigger release

🚀 Release triggered! You can now install nuxt@npm:nuxt3@pr-19403

The implementation is working well and way simpler than what i did. I like it 👍

Can you think a better API/name for the exposed property? Maybe pageRef (similar to pageKey) and layoutRef directly?

Sure ! This would be less confusing (pageRef and layoutRef)

Just one more idea - might we pass page-ref as a prop? So then it removes double-level access?

I think the tempalte transformation would transform :page-ref="page" in to :page-ref="page.value" when a ref need the full ref() object. But it would be nice if that work