-
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
remove component enums in favor of const objects #5930
remove component enums in favor of const objects #5930
Conversation
7936de5
to
c64e73a
Compare
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5930.centralus.azurestaticapps.net |
1 similar comment
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5930.centralus.azurestaticapps.net |
c64e73a
to
79f233c
Compare
| `AccordionExpandMode` | Expand mode for Accordion | `{ | ||
/** * Designates only a single {@link @microsoft/fast-foundation#(AccordionItem:class) } can be open a time. */ | ||
single: "single", | ||
|
||
/** * Designates multiple {@link @microsoft/fast-foundation#(AccordionItem:class) or AccordionItems} can be open simultaneously. */ | ||
multi: "multi", | ||
}` | |
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 formatting for these will need to be handled in the CEMToMarkdown
script
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 it should be but definitely odd that it's not. I'll try running everything again locally - not sure why this wouldn't transform.
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.
OH - These are the new values coming in. I'll take a look before tagging Bill :)
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 Looks like we may need some custom handling to enable proper docs for moving from enums to const objects - is that something you might be able to help with?
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'll take a look.
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.
Per @williamw2 I think we'll need some kind of additional formatting solution here. I don't think we should block on this, but we should figure out that solution to resolve the formatting issue.
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5930.centralus.azurestaticapps.net |
a4ba787
to
2cae9b9
Compare
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5930.centralus.azurestaticapps.net |
1 similar comment
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5930.centralus.azurestaticapps.net |
Just out of curiosity, I'm wondering why const objects are more preferable to enums. |
There are a few reasons, but a big one is that there isn't (yet) the concept of enums in JavaScript and we've had feedback from folks who have ran into difficulty not being able to leverage certain values because of that. Additionally, enums don't really compress, so while a few may not cause much distress, creating a pattern around enums can result in "death by 1000 cuts" on the performance side of things. There is a pretty exhaustive resource here from Typescript on Enums which is worth a look; deep linking specifically to the objects vs. enums example but the whole doc is worth reading IMO: https://www.typescriptlang.org/docs/handbook/enums.html#objects-vs-enums |
# 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 ## π€¨ Rationale FAST decided to stop using enums and use const objects instead microsoft/fast#5930. We want to align with them so that we have consistent APIs (and for reasons outlined in the issue below). Fixes #537. ## π©βπ» Implementation 1. Copy the pattern that FAST used where an enum becomes a const object to store the values and a type union for the type (see `types.ts` files in the PR for examples). 3. Type union has the same name as the const object to simplify imports for clients, so many of our `FooAttribute` types are renamed to `Foo`. 4. Renum enum items to be pascalCase to align with FAST in naming too. Update callers. 5. Fixed Angular directive tests which failed because the inferred type of component harness fields was a single value (e.g. `ButtonAppearance.Outline`) instead of the type (`ButtonAppearance`) so re-assigning the field would fail. 6. Add lint rules to enforce no enums and to allow the types to be PascalCase and values to be camelCase. Applied the naming rules only to `types.ts` to prevent them from affecting other objects. 7. Moved some existing enums into `types.ts` files rather than next to their usages so that the lint rules apply 8. Updated some matrix tests to re-capitalize enum names when they're displayed on component labels; this avoids a visual diff and generally looks better. 9. Added CONTRIBUTING docs explaining enum rules ## π§ͺ Testing Relying on pipeline. ## β Checklist <!--- Review the list and put an x in the boxes that apply or ~~strike through~~ around items that don't (along with an explanation). --> - [x] I have updated the project documentation to reflect my changes or determined no changes are needed.
Pull Request
π Description
This PR updates existing enums for components and converts them to a const object + supported type values.
π« Issues
fixes #5765
π©βπ» Reviewer Notes
π Test Plan
β Checklist
General
$ yarn change
Component-specific
β Next Steps