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

fix(): Replace 'hasOwn' with 'in' operator in typeAssertions check #9812

Merged
merged 2 commits into from
Apr 26, 2024

Conversation

jiayihu
Copy link
Contributor

@jiayihu jiayihu commented Apr 22, 2024

Object.hasOwn is a relatively-recent API so it should not be used. Indeed I noticed this by looking at our production exceptions. I've replaced the usage with just in operator, which for some reason makes TS happier than obj.hasOwnProperty().

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn

Copy link

codesandbox bot commented Apr 22, 2024

Review or Edit in CodeSandbox

Open the branch in Web EditorVS CodeInsiders

Open Preview

@asturur
Copy link
Member

asturur commented Apr 22, 2024

Yes hasOwn is definitely out of our supported browsers specs.
The operator IN also makes more sense for subclassing, as it would be the older code, not sure why we landed on hasOwn initially.

@@ -46,4 +44,4 @@ export const isPath = (fabricObject?: FabricObject): fabricObject is Path => {
export const isActiveSelection = (
fabricObject?: FabricObject
): fabricObject is ActiveSelection =>
!!fabricObject && Object.hasOwn(fabricObject, 'multiSelectionStacking');
!!fabricObject && 'multiSelectionStacking' in fabricObject;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keep in mind that in also checks if property exists down the prototype chain, where hasOwnProperty just makes sure that it is a direct property of an object

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes i was commenting while you posted this, and indeed it also make more sense for the subclasses.
While 'multiSelectionStacking' or 'source' are a property that get defined over and over through the getDefaults() in the contructors, that may not be the case if getDefaults() is emptied and you decide to work on the prototype chain with values. In that case on a subclass ownProperty would fail, but in no.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I used in as well because for the filler.source case it should be an own property typically, whereas with the ActiveSelection case it's even safer if the class is subclassed

@asturur asturur changed the title Replace hasOwn with in operator fix(): Replace 'hasOwn' with 'in' operator in typeAssertions check Apr 22, 2024
@asturur
Copy link
Member

asturur commented Apr 25, 2024

i'll merge this tomorrow if no additional comments are made

@asturur asturur merged commit 4745ae3 into fabricjs:master Apr 26, 2024
20 of 22 checks passed
@jiayihu jiayihu deleted the fix/has-own branch April 26, 2024 08:11
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.

3 participants