Update dropzone context API#11100
Conversation
|
One thing we can do is:
I'm unsure on how best handle name migration. I guess we need to use a different name for the new provider (how about |
|
As per this slack convo: we don't consider public API the use of |
| type: null, | ||
| } ); | ||
|
|
||
| const getDragEventType = ( { dataTransfer } ) => { |
There was a problem hiding this comment.
I guess this could be tested now :)
| const { children } = this.props; | ||
| return children; | ||
| return ( | ||
| <Provider value={ this.dropZoneCallbacks }> |
There was a problem hiding this comment.
Although this is the same as before: how about making DropZone a PureComponent? That way, we prevent doing re-renders every time we setState in this component. We already take care of telling dropZones to render individually (on reset, and if the dropZone needs updating.
There was a problem hiding this comment.
We do need to rerender the dropzone when its state changes. Whether this state is stored in the dropzone it self or in the provider is not that important is it?
There was a problem hiding this comment.
mmm, I'm not sure I follow. Let me clarify what I'm saying:
- we render the
DropZoneby explicitly calling itssetStatemethod from theDropZoneProviderin the places I mentioned. - we also render the
DropZoneby the normal React mechanism: everytime theDropZoneProvideris rendered its children also are. This is the case I think we may want to prevent by convertingDropZoneto aPureComponent.
Does it make more sense now?
There was a problem hiding this comment.
Not really 🤷♂️ How do you transform it to a pure component while keeping setState?
There was a problem hiding this comment.
Oh you mean pure by wrapping it in our pure HoC :). In theory, this shouldn't be necessary. The question could be, why do we not wrap all of our components with it?
The response is that it should probably be optimized on a upper level. and this could hurt more than it helps.
There was a problem hiding this comment.
I've just found out that we don't make PureComponent available through our element package and instead offer the pure HOC. Out of curiosity, why we do that?
There was a problem hiding this comment.
pure works for both functional and class component. PureComponent is a base class only.
Links Gutenberg PR #74903 (dimension validation for sideload endpoint) to its corresponding WordPress Core PR. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add dimension validation to sideload endpoint Validates uploaded image dimensions against expected size constraints in the wp/v2/media/<id>/sideload endpoint. This prevents users from uploading incorrectly-sized images for a specified image size. Validation rules: - 'original' size: must match original attachment dimensions exactly - 'full' and 'scaled' sizes: requires positive dimensions only - Regular sizes: dimensions must not exceed registered size maximums (with 1px tolerance for rounding differences) Also updates existing tests to use appropriately-sized images and adds two new test cases for dimension validation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add backport-changelog entry for Core PR #11100 Links Gutenberg PR #74903 (dimension validation for sideload endpoint) to its corresponding WordPress Core PR. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix sideload filename filter to allow overwriting Remove the file_exists check from filter_wp_unique_filename so sideloaded sub-sizes can replace existing files. The attachment name check is sufficient to prevent unintended overwrites. Also consolidate the positive-dimension check and fix translators comment argument order. * Return early when wp_getimagesize() fails in sideload endpoint Address review feedback: return a WP_Error when wp_getimagesize() returns false (corrupted file, unsupported format) instead of silently proceeding with zero dimensions. This also simplifies the downstream code since $size is now guaranteed to be a valid array. * Fix sideload tests to work with new dimension validation Two tests had stale assertions after the switch to 'thumbnail' size (still expecting 'medium'), and two newer trunk tests used canola.jpg (640x480) in their sideload body, which now fails dimension validation against medium (300x300) and thumbnail (150x150). Use test-image.jpg (50x50) to fit within constraints. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The DropZoneProvider is using the React's legacy context API which will be removed in the next major version and was added as a deprecation in StrictMode in 16.6.0.
This PR updates the DropZoneProvider to the stable React's context API. Note that DropZone functionality has remained untouched and works as it used to.