Skip to content

Conversation

@SuperDJ
Copy link
Contributor

@SuperDJ SuperDJ commented Mar 4, 2025

This PR is based on the changes made in #1940 and so all credits should go to @guizoxxv

This has atleast been requested in: #1550, #1654, #1668 and #1746 as well.

Could also solve vuetifyjs/vuetify#11573.

@chasegiunta
Copy link

@joetannenbaum Can this be merged?

SuperDJ added 2 commits April 16, 2025 09:04
# Conflicts:
#	packages/react/src/Link.ts
#	packages/vue3/src/link.ts
@SuperDJ
Copy link
Contributor Author

SuperDJ commented Apr 16, 2025

@joetannenbaum is there anything that needs to be done before this can be merged?

@motionshots
Copy link

What's the hold up? All checks seems like have passed, why is this still not merged? It's something that is really needed. Why is this PR being ignored?

@joetannenbaum
Copy link
Contributor

Sorry for the lack of communication here, I've been thinking about this PR for a while now.

While I understand the need being addressed here, I don't think this is the way I'd like to go about solving it for two primary reasons:

  • It's a bit opaque, hard to say what props are being spread onto the custom component under the hood from looking at it
  • I can see this opening up a can of worms where we're getting a flood of issues such as "Link component doesn't work with UI library X"

I'd rather invert the solution, something like (totally theoretical, still working on this):

const asLink = useAsLink();

return (
   <MyCustomLink {...asLink('/users', { prefetch: true })} />
);

Benefits are:

  • You know exactly which props are coming from asLink and can include/exclude them as you wish
  • If there are prop collisions, you can alias them in the spread
  • Link itself can use this under the hood to ensure behavior is exactly the same

This is on my list of PRs to examine in the next two weeks.

@chasegiunta
Copy link

chasegiunta commented Jun 2, 2025

Appreciate the response @joetannenbaum . I tend to think it would operate similarly to Vue's native :is functionality where props would fall through to the custom component. In the rare scenario for a collision, the user could use a 2nd argument: eg

<Link href="/dashboard" :as="Button, { collisionProp: 'value' }">

I'm not fully confident this would be better, just giving another DX alternative that could perhaps keep the same native-feeling behavior as before, while still providing an escape hatch for the rare prop collision scenario. This would also avoid having multiple ways for overriding the Link element.

@pascalbaljet
Copy link
Member

I've investigated Joe's proposal today (still WIP), but I'm wondering if anybody is using the router directly to navigate?

<script setup>
import { router } from '@inertiajs/vue3';
</script>

<template>
  <CustomComponent @click="router.visit('/users')"> 
    Users 
  </CustomComponent>
</template>

Even with a solution like useAsLink(), I'd still assume you'd wrap that in a custom component.

@SuperDJ
Copy link
Contributor Author

SuperDJ commented Jul 9, 2025

@pascalbaljet using it in a wrapper function. One of the reasons being that without an href some default browser behaviour breaks. For example ctrl+click / scrollwheel click won't open in a new tab. The other reason is that the router is required to use persistent layouts. What I'm doing is roughly described here.

@pascalbaljet
Copy link
Member

Closed in favor of #2443

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants