-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Download blob: remove downloadjs dependency #56024
Conversation
Size Change: -870 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
7ee6226
to
41fd20e
Compare
Flaky tests detected in 1499a6a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6847000101
|
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 refactoring 👍 I haven’t tested the changes but I really like the idea of introducing a new shared util as part of the @wordpress/blob
package. I shared one concern in regards to the function definition, but overall this PR looks great.
Thanks for the feedback! What was the concern exactly? I wasn't very sure about the function name either 🤔 |
packages/blob/src/index.js
Outdated
a.click(); | ||
document.body.removeChild( a ); | ||
window.URL.revokeObjectURL( url ); | ||
return a; |
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 reason why we want to return the anchor element instead of removing it to avoid memory leak?
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.
Thanks for reviewing!
By "removing" do you mean passively via garbage collection, or something other than removing from DOM?
I returned for two reasons:
- To have something the tests can easily verify
- Just in case consumers what to do something with a link element
Reason 2 is not a very good reason though 😄
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 feel like the anchor element is an implementation detail and shouldn't be exposed to the consumers. What the consumers expect is just a function which triggers downloading something. The same goes with testing, we should avoid testing implementation details if possible (probably a bit trickier here 😅). If the user keeps the returned element then it could be a source of memory leak (though doesn't seem that impactful).
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 agree. I'll remove. Thanks!
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 same goes with testing, we should avoid testing implementation details if possible (probably a bit trickier here)
You were right, but I think managed to hack together a replacement test 🙃
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.
Yeah I guess it doesn't really matter here if we have a solid unit test. Whatever method we end up with will have to rely on mocking implementation details in jsdom. A potential better method would be doing it in integration testing with a real browser for instance, but that's out of the scope and probably not worth it here.
Removes downloadjs dependency Adds tests
- changed a var to anchorElement - regenerate docs
8c48717
to
ef6e22e
Compare
* @param {string} contentType File mime type. | ||
*/ | ||
export function downloadBlob( filename, content, contentType ) { | ||
const file = new window.Blob( [ content ], { type: contentType } ); |
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.
Can we add some validation to the parameters passed?
Should at least a default mime type be defined in case nothing is passed? Will it work correctly if you pass the incorrect content type?
It's going to be a general purpose util available also outside the WordPress context.
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.
Can we add some validation to the parameters passed?
Yes, good idea. Thanks!
Should at least a default mime type be defined in case nothing is passed? Will it work correctly if you pass the incorrect content type?
I'll test this. Maybe text/plain
could work.
It might be that a default mime-type might be incompatible with content<any>
🤔 so in that case we could require all the args.
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.
Will it work correctly if you pass the incorrect content type?
I've tested with a fallback content type of text/plain
and things like zips and images are still downloadable, and the browser somehow works it out.
However, type
is an optional parameter and the default value is ""
, so I think we can can fallback to ""
and require the other args.
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.
Thank you! ❤️ LGTM 👍
…I spec for Blob Updates tests
@gziolo @kevin940726 Thank you for helping with this PR 🙇🏻 @gziolo As mentioned above, I've created a fallback for
If you're happy with the changes, then I'll merge this one tomorrow. Thanks again! |
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.
Looks good 👍🏻
What?
This PR is a follow up to:
Here's what it does:
downloadBlob
— in the@wordpress/blob
package to handle file downloads.download
functionsWhy?
As demonstrated in #55912, the downloadjs package contained some bugs in relation to non-ASCII characters.
The dependency was also not required to handle site exports.
How?
Moves an existing function in reusable blocks to the
@wordpress/blob
package.Testing Instructions
Site editor
Patterns
Reusable blocks
The new function came from here and is basically the same, with the exception that, now, it's pulled from the blob package.
Create a pattern and head over to
/wp-admin/edit.php?post_type=wp_block
Export a pattern as JSON.