feat: functional router-link, fixed #2021

[QingWei-Li]

cc @posva @miljan-aleksic

[miljan-aleksic]

Awesome @QingWei-Li, just seems the TS test didn't pass. Can you check that?

[posva]

It looks like it's missing a type annotation for the destructured param. I'll give it a look but feel free to push any extra commits if you find the solution before I can give it a look 🙂

edit: you can also set the type as any for the moment

[miljan-aleksic]

The functional conversion seems fine and perhaps we could, after the proper tests, merge that as step 1.

As step 2 we should see how to merge the props with the data for the final component.

[posva]

About the merging: it should be ok since the router-link component is already merging the attributes it modifies (classes and attr mostly)

[miljan-aleksic]

Yes but that doesn't cover custom props. Ideally when setting a custom tag, router-link should behave as the component itself and accept any custom prop. I am not seeing anything that covers that, am I missing it?

[QingWei-Li]

@miljan-aleksic All props are in the data, I just extended the data.class, other props will be inherited by the custom component.

[posva]

Sorry for the delay. Before merging this I was wondering if this could have a negative impact on performance if there're too many routes. Maybe we could cache the resolve in the future but I haven't even checked if it's worth doing

[miljan-aleksic]

It may have small performance differences but wouldn't be those routes only rerendered if the parent does? So for example, if you wrap a long list of routes with a standard component those would get the cache benefits from it, right?

[posva]

Yes, but I was thinking of a dynamic content sitting right next to a router link, it will rerender all the time and trigger the resolve function quite often. Imagine having a list of those, it quickly gets heavy 😂

On Wed, 28 Feb 2018, 01:48 Miljan, ***@***.***> wrote: It may have small performance differences but wouldn't be those routes only rerendered if the parent does? So for example, if you wrap a long list of routes with a standard component those would get the cache benefits from it, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2029 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoicVV-_gcanSW1YGyj-DfO7mtL5OSuks5tZKJ1gaJpZM4Rwcsu> .

-- Eduardo San Martin Morote

[miljan-aleksic]

Maybe those edge situations are the ones that should be solved by wrapping router-link in a stateful component :)

[miljan-aleksic]

@posva, I have run into this issue again, is not so isolated as it seems. What can we do to push this forward?

[posva]

Looking again into this, I added a test to check class and style merging happens correctly as well as other tests for #2121
I will need to change that test into a unit one in the future though

[posva]

This will also close #2021 and #1572

[miljan-aleksic]

Any hopes about this getting merged? :)

[yyx990803]

Making <router-link> functional is going to be a breaking change, so this is not going to happen in router 3.x.

To more completely solve this use case here, this is what we are thinking for router v4:

• <router-link> no longer renders an element of itself, instead, the user must provide the element to be rendered via normal slots or scoped slots.

<!-- simple usage: normal slot -->
<!-- implicitly add @click and :href to <a> -->
<router-link to="...">
  <a>Hello</a>
</router-link>

<!-- advanced usage: scoped slot -->
<!-- explicitly get accress to resolved href and click handler and bind yourself -->
<router-link to="..." self-slot-scope="{ href, navigate }">
  <my-button @click="navigate">
    <i slot="icon">x</i>
  </my-button>
</router-link>

[miljan-aleksic]

@yyx990803, what is a self-slot-scope? Some new concept?

Perhaps an intermeddiate router-link-scope component could fill the gap for the v3. No braking changes while providing some useful feedback for v4.

[posva]

Think about self-slot-scope as a shorter version from:

<router-link to="...">
  <template slot-scope="{ href, navigate }">
    <my-button @click="navigate">
      <i slot="icon">x</i>
    </my-button>
  </template>
</router-link>

but in this scenario, a slot-scope on my-button should also work

[miljan-aleksic]

I never saw it, it is a new feature for next vue?

[posva]

It's not something that exists yet, it's not the final api either, so don't worry much about that 🙂

[posva]

@QingWei-Li Thanks a lot for the PR. Given that this change would be a breaking change and that the v-slot api cover the use cases that were initially described at #2021, I recommend to use that when dealing with custom components