Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating <router-link> to no longer use the deprecated :tag property #10793

Merged
merged 1 commit into from
Apr 18, 2024

Conversation

codyrancher
Copy link
Contributor

@codyrancher codyrancher commented Apr 11, 2024

Summary

Updating to no longer use the deprecated :tag property

Areas which could experience regressions

Navigation

Screenshot/Video

Demonstrating that the different types of links around the dashboard app still function

router-link-warning.mp4

Checklist

  • The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
  • The PR has a Milestone
  • The PR template has been filled out
  • The PR has been self reviewed
  • The PR has a reviewer assigned
  • The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
  • The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file wasn't used anywhere in dashboard.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure it's not also in other plugins?

Copy link
Contributor Author

@codyrancher codyrancher Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can't be guaranteed but it's a pretty reasonable assumption given it was old, wasn't used in the app as an example, wasn't documented and I couldn't find any shell (@shell/components/TabbedLinks) imports in github.

},

computed: {
isCurrent() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wasn't used in the file.

Comment on lines -33 to -34
over: false,
menuPath: this.type.route ? this.$router.resolve(this.type.route)?.route?.path : undefined,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These weren't used.

@@ -28,65 +28,10 @@ export default {
},

data() {
return {
near: false,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

near really should be mouseover it seems.

Comment on lines -119 to -125
setOver(val) {
this.over = val;
},

removeFavorite() {
this.$store.dispatch('type-map/removeFavorite', this.type.name);
},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused

Comment on lines -199 to -201
@click="selectType"
@mouseenter="setNear(true)"
@mouseleave="setNear(false)"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • selectType is specific to types in our app while this is being treated as a link to an external page based on the rel="..".
  • setNear is only actually used in relation to showing the Favorite component which isn't possible in this link.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original tests here were mostly exercising and testing router-link instead of our implementation of the Type component.

The new slot API makes these tests non-functional because the RouterLinkStub doesn't fully support the new API. As such I decided to rewrite these tests to achieve the following:

  • Test the Type component instead of RouterLink
  • Test more of the functionality than was tested before
  • Switch to shallowMount instead of mount

More tests could still be written but I think this puts things in a better place than things were. I do recognize that rewriting broken tests is a bit of a code smell though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's in the comments of this file but I'd like to further point out that this is a workaround because the vue/test-utils RouterLinkStub doesn't actually support the new slot api yet. I took the idea from vuejs/vue-test-utils#1803 (comment).

@codyrancher codyrancher marked this pull request as ready for review April 16, 2024 17:58
@codyrancher codyrancher requested a review from cnotv April 17, 2024 15:48
Copy link
Contributor

@cnotv cnotv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see a lot of changes that are unrelated to the : tag property.
May I ask you what are the changes required due to that?

shell/components/nav/__tests__/Type.test.ts Outdated Show resolved Hide resolved
import { createChildRenderingRouterLinkStub } from '@shell/utils/unit-tests/ChildRenderingRouterLinkStub';
import { TYPE_MODES } from '@shell/store/type-map';

// Configuration
Copy link
Contributor

@cnotv cnotv Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we avoid having data outside the tests? It is very time-consuming to have all this list and try to figure out which test it belongs.

This is usually a code smell pointing to a convoluted structure of the unit tests.
Specifically if in your test you are addressing some common points, they must be shared in the same describe(). Therefore you may not need to repeat assignments or you can scope them to make it more readable.

I usually avoid comments like this and aim to deliver tests, but this one really took me too long, I can see already a lot of headaches in the migration phase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what you're suggesting is that we narrow the scope of the shared data, I think that's fair. I've gone ahead and I've done that.

I extended a pattern which initially defined state outside of the tests ece9a33#diff-8c1a0fb993ec56591f5c80663d5ccf84607dee19981b5bc6ff54064fd23676edR8 I could see how you would see that as different but in my mind the pattern is consistent.

I usually avoid comments like this and aim to deliver tests, but this one really took me too long, I can see already a lot of headaches in the migration phase.

Sorry if I'm misinterpreting this but given the context of the rest of this comment I think you're being impolite here. If you're frustrated with me and you'd like to discuss something, we can. If you're thinking I'm incompetent and don't want me working on vue3 or some other aspect of the app please let me and our managers know.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's not about you. I have a personal issue about this which I am trying to address, so I apologize I have caused pressure on you and made you feel uncomfortable. I unfortunately sometimes do not realize it.
I hope you can understand and accept my apologies and also thanks for letting me know.
Just to be clear, it was not something aimed at you but at how I usually do reviews in general.

I will try to be more careful in the future.

shell/components/nav/__tests__/Type.test.ts Outdated Show resolved Hide resolved
rak-phillip
rak-phillip previously approved these changes Apr 17, 2024
Copy link
Member

@rak-phillip rak-phillip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionally, I think this looks good and the refactoring aligns with recommendations for addressing the deprecated tag prop1

Footnotes

  1. https://router.vuejs.org/guide/migration/#Removal-of-event-and-tag-props-in-router-link-

@cnotv
Copy link
Contributor

cnotv commented Apr 18, 2024

I can see a lot of changes that are unrelated to the : tag property. May I ask you what are the changes required due to that?

Thanks @rak-phillip got it now 😄

@codyrancher
Copy link
Contributor Author

I can see a lot of changes that are unrelated to the : tag property.
May I ask you what are the changes required due to that?

This questions seems odd to me because I don't think this change meanders very far from just the :tag property. But a summary is:

  • For each file that used :tag we need to switch to the slot api
    • First follow https://eslint.vuejs.org/rules/no-deprecated-router-link-tag-prop
    • Second, those docs were out of date and I also had to add the custom attribute to each area
    • Those changes would have to happen to these files
      • shell/components/SideNav.vue
      • shell/components/TabbedLinks/index.vue
        • Do we want to make changes here even though the file isn't used anywhere? That seemed like wasted effort to me.
      • shell/components/nav/Header.vue
      • shell/components/nav/Type.vue
  • After making those changes we also need to update the Type.tests.ts because they broke.
    • The lack of support for slots in RouterLinkStub makes all of the original tests useless because ultimately it would come down to what slot props get passed. We could either delete those tests or rewrite them to exercise the Type component.

What's notably missing from that list is the dead code that I deleted from Type.vue. That wasn't necessary but since I was testing the component it seemed like a good time to delete dead code that didn't need to be exercised by a test.

@codyrancher
Copy link
Contributor Author

@cnotv I know @rak-phillip already approved this but I think we need to get through the feedback on this and hash things out otherwise going forward with vue 3 is going to be rough.

@cnotv
Copy link
Contributor

cnotv commented Apr 18, 2024

@cnotv I know @rak-phillip already approved this but I think we need to get through the feedback on this and hash things out otherwise going forward with vue 3 is going to be rough.

I think it would be sufficient for one of us to approve the PR to proceed. Sometimes I may be overzealous or confused on some points, so I will try to be more careful from my side later on. If there are some other points which you were thinking about, let's have a chat about it, with the hope I can be helpful.

@cnotv cnotv self-requested a review April 18, 2024 14:40
Copy link
Contributor

@cnotv cnotv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@codyrancher codyrancher merged commit e09df1d into rancher:master Apr 18, 2024
25 checks passed
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.

3 participants