-
Notifications
You must be signed in to change notification settings - Fork 802
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
Share the block style selector code #14383
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: February 11, 2020. |
scruffian, Your synced wpcom patch D37842-code has been updated. |
I'm sure this has been discussed somewhere and I'm not questioning this, but I'm curious why not just use Gutenberg's built-in |
Gutenberg's built in style switcher only deals with changing the class name for the block, not for changing attributes, which is how this works. |
We're using a similar approach in the Eventbrite block, but using an image rather than a block preview for the "in page" embed option, since that option takes a while to load (during which the preview is blank). https://github.com/Automattic/jetpack/pull/14075/files#diff-67c4a00b3bd3c01b617670a5fd26e417R148 What do you think about making this more generic by using a prop for rendering the preview? |
We could make it more generic by passing in the preview mechanism as a function. However I'd rather keep this component as close to the core component as possible, with the hope of eventually getting it merged in there. We could look into how to integrate with Eventbrite once this (or that) PR merges... |
I'd make the same argument in the Core context! The pattern is more broadly usable if it doesn't lock you into a very specific way of rendering a block preview, like it does now. But do what you think is best--what I have now for the Eventbrite block works just fine. |
Oh yea, that's annoying limitation indeed. We used style picker in Tiled gallery block but needed the style information in JS as well. There's a helper for that in core and in Jetpack:
jetpack/extensions/shared/block-styles.js Lines 7 to 36 in aa3ad69
By defining styles semantically in the block, you give Gutenberg UI a chance to decide best how to surface that; it might change over time or be surfaced differently in various editor instances (think mobile app version, mobile web version, widgets screen, full site editing mode, writing mode, and generally things we haven't seen yet.) |
@simison I agree, this needs more thought. I think this PR is still valuable in removing the duplicate code, but we should think more about how we interact with block styles - in a different PR! |
Absolutely! 👍 :-) Just wanted to highlight other mechanisms in 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.
This will need a rebase now, and tests are failing because of the React import.
* External Dependencies | ||
*/ | ||
import classnames from 'classnames'; | ||
import { memo } from 'React'; |
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.
This is breaking things:
Module not found: Error: Can't resolve 'React' in '/home/travis/build/Automattic/jetpack/extensions/shared/components/block-styles-selector'
Can we do without all of React here? Can we get it from @wordpress/element
instead?
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.
There is a useMemo
HOC in @wordpress/element
, but when I use this I get an error from React. Looking into it some more...
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.
Ok I added a commit to take care of this too.
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.
We might be able to change this to useMemo
but we need useSelect
which (as you've seen) also isn't available. It's a shame, but treating it like we have for the changes to BlockPreview
makes sense to me.
4ee07e7
to
98a0b3e
Compare
scruffian, Your synced wpcom patch D37842-code has been updated. |
I added a fix for #14466 too. |
Looks good, and works as expected. It's a shame about the hooks, but never mind. |
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.
This seems to work well on my end. I'll merge this now, and take care of the matching wpcom reference since it introduces a new file.
Should we now update the Eventbrite block to use this too?
* share the block style selector code * Memoized the style previews to prevent them from rerendering * remove unused CSS * Remove unused class * Dont show block previews unless they are supported * use the internal memo if it exists * don't try to render the style selector if there's no valid block Co-authored-by: Paul Bunkham <[email protected]>
Cherry-picked to |
r202313-wpcom |
Logged in #14527 |
Fixes #14466
Changes proposed in this Pull Request:
Testing instructions:
Proposed changelog entry for your changes: