-
Notifications
You must be signed in to change notification settings - Fork 261
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
Conversation
c3524c2
to
0851f02
Compare
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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.
over: false, | ||
menuPath: this.type.route ? this.$router.resolve(this.type.route)?.route?.path : undefined, |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
setOver(val) { | ||
this.over = val; | ||
}, | ||
|
||
removeFavorite() { | ||
this.$store.dispatch('type-map/removeFavorite', this.type.name); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused
@click="selectType" | ||
@mouseenter="setNear(true)" | ||
@mouseleave="setNear(false)" |
There was a problem hiding this comment.
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 therel=".."
.setNear
is only actually used in relation to showing the Favorite component which isn't possible in this link.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this 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?
import { createChildRenderingRouterLinkStub } from '@shell/utils/unit-tests/ChildRenderingRouterLinkStub'; | ||
import { TYPE_MODES } from '@shell/store/type-map'; | ||
|
||
// Configuration |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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
Thanks @rak-phillip got it now 😄 |
0851f02
to
e21f0ca
Compare
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:
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. |
e21f0ca
to
e205b56
Compare
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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