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

feat(dialog): implement <dialog> interface #5120

Merged
merged 6 commits into from
Apr 14, 2022

Conversation

bennypowers
Copy link
Contributor

@bennypowers bennypowers commented Aug 29, 2021

Pull Request

πŸ“– Description

adds close and cancel 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

  • I have included a change request file using $ yarn change
  • I have added tests for my changes.
  • I have tested my changes.
  • I have updated the project documentation to reflect my changes.
  • I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

⏭ Next Steps

@@ -96,6 +96,8 @@ export class Dialog extends FoundationElement {
*/
public dismiss(): void {
this.$emit("dismiss");
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

  1. 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
  2. Prepend **DEPRECATED** to description members

HTMLDialogElement has close(), show(), and showModal()

https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement

Copy link
Member

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!

Copy link
Contributor Author

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

Copy link
Contributor Author

@bennypowers bennypowers Mar 8, 2022

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

Copy link
Contributor

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.

Copy link
Contributor

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/

adds `close` and `cancel` events to dialog
@bennypowers bennypowers marked this pull request as ready for review March 8, 2022 14:09
@bennypowers
Copy link
Contributor Author

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.

@chrisdholt
Copy link
Member

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!

@EisenbergEffect
Copy link
Contributor

@chrisdholt I'm assigning this to you so it doesn't get lost in the mix.

@chrisdholt
Copy link
Member

chrisdholt commented Apr 14, 2022

This is so odd I'm not able to repro the failures locally. I'm going to check out this branch and push a PR to see if it still repro's...

Copy link
Member

@chrisdholt chrisdholt left a 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 :)

@chrisdholt chrisdholt merged commit 9f670f6 into microsoft:master Apr 14, 2022
@chrisdholt
Copy link
Member

πŸŽ‰ Thanks @bennypowers!

@bennypowers
Copy link
Contributor Author

So much green!

Thanks @chrisdholt for fixing this πŸ€—

@jattasNI jattasNI mentioned this pull request May 5, 2022
1 task
jattasNI added a commit to ni/nimble that referenced this pull request May 10, 2022
# 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.
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.

5 participants