-
Notifications
You must be signed in to change notification settings - Fork 83
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
feat: add target property to side-nav-item #7088
Conversation
46a5aac
to
3763ae8
Compare
/** | ||
* The target of the link. Works only when `path` is set. | ||
*/ | ||
target: string | null | 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.
Should there be a type here that only accepts something like '_self' | '_blank' | '_parent' | '_top'
?
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.
target
in HTMLAnchoElement
doesn't seem to get any special type (source)
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.
A niche use-case would be to configure a specific browsing context, which could have any name apparently (vaadin/flow-components#5091 (comment)). So the union type would need to include string
as well. But just starting with string
is fine IMO 👍
it('should not set target attribute to the anchor when target is empty string', async () => { | ||
item.target = ''; | ||
await nextRender(); | ||
expect(anchor.getAttribute('target')).to.be.not.ok; |
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.
From my testing the attribute is still defined for an empty string, the assertion here doesn't work as intended. Would be better to use hasAttribute
for checking the attribute existence IMO.
If we want to avoid defining the attribute it requires further changes. Don't see why it would be necessary though. So maybe just remove the test case.
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.
Yeah, you're right. Based on this comment, I also changed the assertion in the previous test to use hasAttribute
instead.
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
This ticket/PR has been released with Vaadin 24.4.0. |
Description
Make it possible to define a
target
attribute to forward its value to the internal anchor element present in the<vaadin-side-nav-item>
component.Part of vaadin/flow-components#5091
Type of change