-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
compose: Add types to withInstanceId and corresponding hook #31341
Conversation
Size Change: +766 B (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
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 good to me 👍
*/ | ||
const withInstanceId: PropRemovingHigherOrderComponent< { | ||
instanceId: string | number; | ||
} > = createHigherOrderComponent( |
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.
Does it make sense to extract a InstanceIdProps
or even export it? The type definition is used twice in the 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.
I originally did that but it made the extracted documentation worse because it made the type PropRemovingHigherOrderComponent< InstanceIdProps >
instead of listing the props that are removed. Do you think it's still worth aliasing the type in that 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.
I would personally do it and document the InstanceIdProps
type. But I don't mind either way.
To make documentation clearer, I would also rename the HOC type to PropInjectingHigherOrderComponent
. Before it's too late after the NPM package is published and backward compatibility becomes an issue.
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.
FWIW we don't fully export the type from the package so there's no concern about change it immediately, but I do like that name better.
* @param {Object} object Object reference to create an id for. | ||
* @param {string} prefix Prefix for the unique id. | ||
* @param {string} preferredId Default ID to use. | ||
* @param {any} object Object reference to create an id for. |
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 type should be object
instead of any
(or unknown
). The K
type in WeakMap<K, V>
is supposed to extend object
. That prevents usages with primitive types that can't be WeakMap
keys.
useInstanceId( 'hello' );
will throw an exception at runtime (invalid value used as weak map key). And if the param's type is object
, it will be a type error, too.
5c7902a
to
55a3ccc
Compare
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.
👍
*/ | ||
const withInstanceId: PropRemovingHigherOrderComponent< { | ||
instanceId: string | number; | ||
} > = createHigherOrderComponent( |
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 would personally do it and document the InstanceIdProps
type. But I don't mind either way.
To make documentation clearer, I would also rename the HOC type to PropInjectingHigherOrderComponent
. Before it's too late after the NPM package is published and backward compatibility becomes an issue.
Description
Adds types to
withInstanceId
and fixes the types on the correspondinguseInstanceId
hook.useInstanceId
is changed to useany
instead ofunknown
as the underlyingWeakMap
must useany
.How has this been tested?
No runtime changes, just type additions so as long unit tests and type checks pass we should be good
Part of #18838
Types of changes
New feature.
Checklist:
*.native.js
files for terms that need renaming or removal).