-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add multi-block transform functionality. #3357
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3357 +/- ##
==========================================
+ Coverage 31.3% 31.76% +0.46%
==========================================
Files 246 246
Lines 6741 6856 +115
Branches 1209 1243 +34
==========================================
+ Hits 2110 2178 +68
- Misses 3896 3932 +36
- Partials 735 746 +11
Continue to review full report at Codecov.
|
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 really awesome, I like it.
-
Now that we have this, I think we should update the
list -> paragraph
single transformation to create multiple paragraphs, one for each list item. And for consistency, I'd also update theparagraph -> list
transformation to always create a list with one item (and avoid splitting on brs) cc @jasmussen -
Images to gallery is great too, but same here, we should now add a
gallery => images
transform.
Overall, the code looks good, I like the approach. Really great work here
editor/block-switcher/index.js
Outdated
onTransform( block, name ) { | ||
( state, ownProps ) => { | ||
const isMultiBlock = ! ownProps.uid && getSelectedBlockCount( state ) > 1; | ||
const blocks = isMultiBlock ? getMultiSelectedBlocks( state ) : |
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.
It feels a bit weird to retrive the blocks from the state when there's a multiselection and retrieve them from the uid
when passed. Can we update the component to always use a uids
prop To make this consistent?
blocks/api/test/factory.js
Outdated
@@ -144,7 +144,7 @@ describe( 'block factory', () => { | |||
value: 'ribs', | |||
} ); | |||
|
|||
const transformedBlocks = switchToBlockType( block, 'core/updated-text-block' ); | |||
const transformedBlocks = switchToBlockType( [ block ], 'core/updated-text-block' ); |
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.
To avoid all these changes, we could have used lodash's castArray
in the switchToBlockType
function
This sounds good to me. Given the recent improvements in cross-block selection, and the hope that we can make multi-select transformations like selecting three paragraphs and transforming those into a list, this makes a lot of sense. I think @mtias noted an opportunity around lists as well, that if we were to make each list item into its own block, we might be able to do some cool list sorting things as part of that. |
This probably closes #539 |
d3c44a4
to
06a86ae
Compare
3abd85e
to
3353717
Compare
editor/block-switcher/index.js
Outdated
const blocksToBeTransformedFrom = reduce( getBlockTypes(), ( memo, type ) => { | ||
const transformFrom = get( type, 'transforms.from', [] ); | ||
const transformation = find( transformFrom, t => t.type === 'block' && t.blocks.indexOf( block.name ) !== -1 ); | ||
const transformation = find( transformFrom, t => t.type === 'block' && t.blocks.indexOf( sourceBlockName ) !== -1 && ( ! isMultiBlock || t.isMultiBlock ) ); |
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.
Minor: The line is a bit too long
@@ -35,6 +36,7 @@ function HeaderToolbar( { hasUndo, hasRedo, hasFixedToolbar, undo, redo } ) { | |||
label={ __( 'Redo' ) } | |||
disabled={ ! hasRedo } | |||
onClick={ redo } /> | |||
{ isMultiBlockSelection && <BlockSwitcher key="switcher" uids={ selectedBlockUids } /> } |
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.
From a design perspective, this is always showing up in the Header even if I choose to show the block toolbar next to the block, I think we might want to show the switcher in the first selected block's toolbar when this option is toggled. (You can toggle this option in the ellipsis menu at the top right of the editor) cc @jasmussen
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.
Regarding this point, I agree, adding the transform drop-down to the tools of the first block may be an option if the config preference is set. But I think adding this logic would increase the scope of this PR and make it harder to review. If it is ok for you I would prefer to add this logic in a future PR.
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.
Awesome PR
I think the work done here is very nice, and yes it does indeed close #539. The current mockups put the transformation into the ellipsis menu, like Riad suggests. But an argument can be made that it's okay to show this in the toolbar. If it's significantly easier to do so, we may do that as a first step before we put the transformation inside the ellipsis menu, then we can test this as an interface first, and move on to the ellipsis if we find that is more contextual and sufficiently discoverable. Let's discuss the perspectives first, though, and @karmatosed and @mtias feel free to chime in:
None of the above have to be addressed in this PR, but it's context for deciding whether we want to move the transformations into an ellipsis now, or later. Like I said, if it's a ton of extra work, it's probably okay to try and go with this now, but at a minimum we'd want to fix this extra space that appears: ☝️ Note how the switcher moves to the left on multi select. It should align with a normal text block toolbar. |
A quick next enhancement could be to explode the contents of the switcher dropdown into direct buttons for heading, quote, list, pre and verse, as opposed to keeping them in a dropdown. |
Also agree: awesome PR! Thank you! |
This already works :) |
Actually, I was not talking about moving those to the ellipsis for now. I was just saying we should be consistent with the position of the block switcher of one selected block: It shows in the header's toolbar if the block toolbar is "fixed" and shows in the contextual toolbar if it's not. -- That said, I think moving all these switchers to the block's ellipsis menu should be better but I also think this is a separate task :) |
08985c8
to
993e7fb
Compare
Hi @jasmussen, @youknowriad, I added a new very simple commit, that makes the space between transforms of multiple blocks and single blocks the same, solving the problem identified by @jasmussen. |
If Riad approves so do I! |
💥💥💥 |
Thank you for your inputs it was merged :) Now the work will continue to address the other points. |
Great work here. I agree with moving this to the ellipsis menu for the selected group of blocks. I actually missed the transformation in the header. |
Description
This PR's implements multi-block transform functionality. Allowing the user to transform a selection of multiple blocks into other block types. It changes blocks api. When specifying the transform the developer can set isMultiBlock to true to set that the transform is able to handle more than one block.
Multiblock transforms were already added to transform from multiple paragraphs into a list and multiple images into a gallery.
Testing
Create multiple paragraphs, select them, go to the transform area and transform them into a list.
Add multiple images select them and transform them into a gallery.
Screenshots: