-
Notifications
You must be signed in to change notification settings - Fork 601
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(dialog): implement <dialog> interface #5120
Conversation
b0f9f7a
to
8f5be14
Compare
@@ -96,6 +96,8 @@ export class Dialog extends FoundationElement { | |||
*/ | |||
public dismiss(): void { | |||
this.$emit("dismiss"); |
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.
@bennypowers Thanks for this! @EisenbergEffect thoughts on how we might deprecate the dismiss
event on line 98? If we can mark it deprecated somehow we can add a comment above to remove in the next major version.
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.
sounds like a good use for custom-elements.json
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.
@bennypowers Does the custom-elements.json have a way to indicate that something is deprecated? If not, perhaps we just leave the event in there for now with a comment that it's deprecated, and then remove any documentation on this either on our site or the spec. Then, we can stop publishing the event in a future version.
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.
Looking more at the code, I'm inclined to deprecate the dismiss
and hide
methods, keeping their old event and state behaviors in place. Then add new cancel()
and close()
methods with the improved event patterns.
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.
there are two options in custom-elements.json
- use a non-standard field and consume it in your own tooling. I opened deprecated flagΒ webcomponents/custom-elements-manifest#84 to track the idea in the spec
- Prepend
**DEPRECATED**
to description members
HTMLDialogElement
has close()
, show()
, and showModal()
https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement
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.
Would love this contribution @bennypowers, especially now that Dialog is a priority for Interop2022 - ideally this can set us up for success in just using that element long term! If you run into issues, we'll find a way to unblock you!
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.
Maintainers should please permit CI to run
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.
@bennypowers Thanks for this! @EisenbergEffect thoughts on how we might deprecate the
dismiss
event on line 98? If we can mark it deprecated somehow we can add a comment above to remove in the next major version.
Also, since this thread started, deprecated
got added to the custom-elements manifest schema
The way I've been handling this in patternfly-elements is like so
/**
* `<some-element>`
* @fires {MyEvent} my-event - when something happens {@deprecated use `your-event`}
* @fires {YourEvent} your-event - when something happens
*/
Although @deprecated
is a block-level tag, I scripted my analyzer to pick them up inline anyways
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.
@williamw2 Since you are investigating custom elements manifest, it would be great if we could support the new deprecated
feature. It might be good to sync up with @nicholasrice on some of this as well. I think there's a possibility of using the API extractor metadata from our code to generate the custom elements manifest. There was recent work which Nick contributed to, to enable custom documentation tags. I think it's all merged and ready for use now. If we can use that, we can add custom tags for slots, deprecated, etc. and then use the API extractor metadata to generate the manifest from our code.
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.
Yep, docs for that feature are here: https://api-extractor.com/pages/configs/tsdoc_json/
585f3c0
to
255a957
Compare
adds `close` and `cancel` events to dialog
255a957
to
14d17aa
Compare
Having rebased and taken a look at the state of the PR, I'm still mostly sure this is code-complete, but found I was unable to run the lint or test steps after an hour of fiddling. I leave that in maintainers hands, and am happy to make any tooling-related fixes necessary. |
I'll pull this down today and see if we can't get things running locally. If all looks good and passes here, I don't see an issue. Thanks @bennypowers! |
@chrisdholt I'm assigning this to you so it doesn't get lost in the mix. |
This is so odd |
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.
@bennypowers I think the issue here with the tests may be that the button's click event in the "close" test doesn't do anything. So the test is failing accurately - wasDismissed
is not being called. I'm not sure why that's causing everything else to fail as well, but it is.
I think given the intent of when this event fires after looking at the Dialog class (when the hide()
method is called), adding the suggestion on the above lines should fix the tests. If you want to push that change I think we'll see all green and be good to finally get this in. Thanks for bearing with us on this one :)
Co-authored-by: Chris Holt <[email protected]>
π Thanks @bennypowers! |
So much green! Thanks @chrisdholt for fixing this π€ |
# Pull Request ## π€¨ Rationale We want to keep our dependencies on FAST up to date. There are a couple of issues that depend on fixes. e.g. #543, #523 ## π©βπ» Implementation 1. npm install all of the @microsoft/fast... packages @latest (as of late last week) 2. Fix a test failure in nimble-components drawer.spec.ts. We were firing a custom `cancel` event but [FAST started firing their own](microsoft/fast#5120), resulting in 2 events instead of the expected 1. See discussion on this PR for details. (thanks @msmithNI for investigating!) 3. Fix a type error in nimble-text-area.directive.spec.ts. This was a result of FAST's change to use const objects and type unions instead of enums microsoft/fast#5930 (it made it so the computed type of that field was the specific value of the enum rather than the type of the enum; the fix widens the type). We'll update the rest of the codebase to use this pattern and address #537 in a follow-up PR #546 since it's a pretty large change. ## π§ͺ Testing Mostly relying on pipeline with some light manual testing of storybook. ## β Checklist - [x] I have updated the project documentation to reflect my changes or determined no changes are needed.
Pull Request
π Description
adds
close
andcancel
events to dialog. See material-components/material-web#1583π« Issues
π©βπ» Reviewer Notes
I was unable to get the repo up and running due to some mismatched ramda types (see discord chat)
π Test Plan
β Checklist
General
$ yarn change
Component-specific
β Next Steps