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(): support aborting promises/requests #7827

Merged
merged 57 commits into from Jun 30, 2022
Merged

feat(): support aborting promises/requests #7827

merged 57 commits into from Jun 30, 2022

Conversation

ShaMan123
Copy link
Contributor

@ShaMan123 ShaMan123 commented Mar 24, 2022

@ShaMan123
Copy link
Contributor Author

I think we should consider migrating XMLHttpRequest to fetch

if (!json) {
return;
return Promise.reject(new Error('fabric.js: `json` is undefined'));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

BREAKING

@asturur
Copy link
Member

asturur commented Jun 26, 2022

read all the PR, and the only thing i disagree is providing the abort controller ourselves.
The abort signal from the controller should be sent from outside from the developer ( that wants to use it ), this is how i interacted with aws uploads in s3 for example, they accept an abort signal from outside, but don't create one for you.
This would also remove the issue with the supported node version.

We would also not need to provide a method to interrup the current task, supporting the existance of an abort signal is all we should surface.

Copy link
Contributor Author

@ShaMan123 ShaMan123 left a comment

Choose a reason for hiding this comment

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

the only thing i disagree is providing the abort controller ourselves.

src/mixins/canvas_serialization.mixin.js Outdated Show resolved Hide resolved
src/shapes/image.class.js Outdated Show resolved Hide resolved
Copy link
Member

@asturur asturur left a comment

Choose a reason for hiding this comment

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

I insist for the Abort controller being passed from outside in the functions where we decided to generate it automatically.
That does not change the functionality you are proposing, and allows for better integration of loading tasks.
The operation can be cancelled from inside or from outside, and most importantly the same abort signal from the used abort controller can be passed to other systems that needs to be cancelled on coordination.

Other than it allow us to leave node 14 support on.

@ShaMan123
Copy link
Contributor Author

I still don't understand how it solves the bug I described or how I can set src using img.set. I am unconvinced.
And regarding passing the signal down - it's how I wrote it - it does that exactly.

@asturur
Copy link
Member

asturur commented Jun 28, 2022

i don't see set('src', value) anywhere defaulting to setSrc, where that happens?

@ShaMan123
Copy link
Contributor Author

ShaMan123 commented Jun 28, 2022

i don't think we should guard against this internally. I want to leave loading patterns to the developer.

I can understand this and live with it but I think it's a bad idea because it will surface fake bugs from devs. And it is expected behavior not to have race conditions.

But not img.set('src',...)

EDITED

I gave a deeper look. Does img.set('src',...) do anything? Seems not. If that's the case I don't have any objections and would propose to support img.set('src',...) in the future.

@ShaMan123
Copy link
Contributor Author

img.set('src',...)

It doesn't which IMO should be viewed as a bug

@asturur
Copy link
Member

asturur commented Jun 28, 2022

indeed src is not an image of the property, setSrc is like, a, change the element. It does not even update it, it totally changes it ( and that is fine because the previous one could be a canvas element ).
I m not even sure if setSrc is a good idea in general, it looks like a wrapper for setElement with a loader, but on top of that then changes the image size, while setElement does't.
No one of them is resetting cropX and cropY, creating potentially weird visual bugs when cropX is bigger than the new width and similar for cropY.

@ShaMan123
Copy link
Contributor Author

Good point
So perhaps src should only exist on from/to object

I now understand your point

@asturur
Copy link
Member

asturur commented Jun 28, 2022

img.set('src',...)

It doesn't which IMO should be viewed as a bug

probably the bug is the name of the method. Probably that is setElementFromSrc
fabric.Image does not have a src, it has a drawable element, we have utils to load new drawable elements ( like fabric.util.loadImage ) and we can improve how they are swapped the element.

@ShaMan123
Copy link
Contributor Author

Yeah we should rename and add logic
I think we should rename Image as well because it can be Video as well

@github-actions
Copy link
Contributor

github-actions bot commented Jun 28, 2022

Code Coverage Summary

> fabric@5.1.0 coverage:report
> nyc report --reporter=lcov --reporter=text

-----------|---------|----------|---------|---------|-----------------------------------------------
File       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s                             
-----------|---------|----------|---------|---------|-----------------------------------------------
All files  |   83.18 |    76.14 |   85.68 |   82.91 |                                               
 fabric.js |   83.18 |    76.14 |   85.68 |   82.91 | ...,30945,31019,31030-31095,31218,31317,31553 
-----------|---------|----------|---------|---------|-----------------------------------------------

@github-actions
Copy link
Contributor

github-actions bot commented Jun 28, 2022

Code Coverage Summary

> fabric@5.1.0 coverage:report
> nyc report --reporter=lcov --reporter=text

-----------|---------|----------|---------|---------|-----------------------------------------------
File       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s                             
-----------|---------|----------|---------|---------|-----------------------------------------------
All files  |   83.22 |    76.14 |   85.68 |   82.95 |                                               
 fabric.js |   83.22 |    76.14 |   85.68 |   82.95 | ...,30949,31023,31034-31099,31222,31321,31557 
-----------|---------|----------|---------|---------|-----------------------------------------------

@github-actions
Copy link
Contributor

github-actions bot commented Jun 28, 2022

Code Coverage Summary

> fabric@5.1.0 coverage:report
> nyc report --reporter=lcov --reporter=text

-----------|---------|----------|---------|---------|-----------------------------------------------
File       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s                             
-----------|---------|----------|---------|---------|-----------------------------------------------
All files  |   83.18 |    76.14 |   85.68 |   82.91 |                                               
 fabric.js |   83.18 |    76.14 |   85.68 |   82.91 | ...,30949,31023,31034-31099,31222,31321,31557 
-----------|---------|----------|---------|---------|-----------------------------------------------

1 similar comment
@github-actions
Copy link
Contributor

github-actions bot commented Jun 28, 2022

Code Coverage Summary

> fabric@5.1.0 coverage:report
> nyc report --reporter=lcov --reporter=text

-----------|---------|----------|---------|---------|-----------------------------------------------
File       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s                             
-----------|---------|----------|---------|---------|-----------------------------------------------
All files  |   83.18 |    76.14 |   85.68 |   82.91 |                                               
 fabric.js |   83.18 |    76.14 |   85.68 |   82.91 | ...,30949,31023,31034-31099,31222,31321,31557 
-----------|---------|----------|---------|---------|-----------------------------------------------

@ShaMan123 ShaMan123 requested a review from asturur June 28, 2022 10:33
Copy link
Contributor Author

@ShaMan123 ShaMan123 left a comment

Choose a reason for hiding this comment

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

READY!

@asturur
Copy link
Member

asturur commented Jun 30, 2022

Merging this, i ll follow up restoring node 14 adding a polyfill in the dev-deps

@asturur asturur merged commit 78b7029 into master Jun 30, 2022
@ShaMan123 ShaMan123 deleted the fix-json-load branch September 11, 2022 23:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants