-
Notifications
You must be signed in to change notification settings - Fork 1k
[labs/react] Remove deprecated syntax and remove extra class component #4027
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
Conversation
🦋 Changeset detectedLatest commit: b2954e2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
reactive-element-list
render
update
update-reflect
|
| } | ||
|
|
||
| // But don't dirty check properties; elements are assumed to do this. | ||
| node[name as keyof E] = value as E[keyof E]; |
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.
Raising this line above the check at 160 seems to maybe change logic? Is this expected?
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.
All tests of expected behavior passes. I think it's a bit more correct to set the property to these nullish values then remove the attribute, rather than removing the attribute only and leaving the previous property values as it currently is.
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.
Any way we can add a test for what we think is the more correct behavior? I think it'll matter for properties that don't reflect from an attribute, or have a name that differs from the attribute.
Like for props: {ariaChecked: null}? The new behavior should be correct where the old was wrong.
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.
ariaChecked is kind of a weird one. React would normally not accept it as a valid prop on native elements and do nothing with it. It expects aria-checked as a prop to set that attribute, and if the user does that we'd never enter this logic and let React handle it.
Our wrapped component does accept ariaChecked as a prop since we find it in HTMLElement.prototype and set it. It's not quite the idiomatic React use case but since we're setting it we should remove. I can add a test for that.
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.
So turns out el.ariaChecked = true doesn't reflect to aria-checked in Firefox so users shouldn't really be doing that.
Our types disallow ariaChecked to be passed in as a prop and only accepts aria-checked. I'm now thinking we shouldn't have to add a test for something users shouldn't do.
Edit: Doesn't hurt to add for Chrome/Safari behavior anyway. Added a test just to check for the absence of the attribute after setting and "unsetting" with undefined/null.
| * `onfoo` prop will have the type `(e: FooEvent) => void`. | ||
| */ | ||
| export type EventName<T extends Event = Event> = string & { | ||
| __event_type: T; |
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.
while you're here, we'd normally write this as __eventType, ie the __ is a prefix, the whole identifier is not snake_case.
| } | ||
|
|
||
| // But don't dirty check properties; elements are assumed to do this. | ||
| node[name as keyof E] = value as E[keyof E]; |
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.
Any way we can add a test for what we think is the more correct behavior? I think it'll matter for properties that don't reflect from an attribute, or have a name that differs from the attribute.
Like for props: {ariaChecked: null}? The new behavior should be correct where the old was wrong.
| ); | ||
| return React.createElement(tagName, { | ||
| ...reactProps, | ||
| ref: (node: I) => { |
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 creates a new closure every render. Can we hoist it?
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 needs to be declared in the scope of the function component so we can assign to elementRef.current as well. I think a new closure every render here is unavoidable and using useCallback seems overkill for this.
AndrewJakubowicz
left a 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 love all the great React labs package improvements!
24f9c73 to
bd84a2a
Compare
AndrewJakubowicz
left a 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.
Nice updates & nice test!
forwardRefrather than creating a class component. This removes an extra React component of the same name showing up in the component tree.WebComponentPropsandReactWebComponentand added jsdoc.