-
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
Add quote↔text block switching; add block switcher validation #465
Changes from 7 commits
1aed21a
98a87ea
0b44dcd
decdfcb
c30cd92
d79463b
854f1bb
a411591
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,20 +16,50 @@ registerBlock( 'core/quote', { | |
category: 'common', | ||
|
||
attributes: { | ||
value: query( 'blockquote > p', html() ), | ||
content: query( 'blockquote > p', html() ), | ||
citation: html( 'footer' ) | ||
}, | ||
|
||
transforms: { | ||
from: [ | ||
{ | ||
type: 'block', | ||
blocks: [ 'core/text' ], | ||
transform: ( { content } ) => { | ||
return { | ||
content, | ||
}; | ||
}, | ||
}, | ||
], | ||
to: [ | ||
{ | ||
type: 'block', | ||
blocks: [ 'core/text' ], | ||
transform: ( { content, citation } ) => { | ||
if ( citation ) { | ||
return new Error( | ||
'Quote citation would be lost on transform.' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should just create two paragraphs instead of erroring here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't love this because switching a quote block to a text block and back would leave the citation as a separate paragraph. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not a problem for me, because it's an explicit change asked by the user (maybe discuss in the comment bellow) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is an acceptable data loss. I think the razor we should hold any transformation against is that it has to be non-destructive, which is fuzzy enough that it would okay this transformation, but disallow transforming it into a gallery for example (which would make no sense). In other words, yes you might lose some formatting, but the data is still there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I don't have a big problem with this specific case, I'll change it to include the citation as a separate paragraph. |
||
); | ||
} | ||
return { | ||
content, | ||
}; | ||
}, | ||
}, | ||
], | ||
}, | ||
|
||
edit( { attributes, setAttributes } ) { | ||
const { value, citation } = attributes; | ||
const { content, citation } = attributes; | ||
|
||
return ( | ||
<blockquote className="blocks-quote"> | ||
<Editable | ||
value={ fromValueToParagraphs( value ) } | ||
value={ fromValueToParagraphs( content ) } | ||
onChange={ | ||
( paragraphs ) => setAttributes( { | ||
value: fromParagraphsToValue( paragraphs ) | ||
content: fromParagraphsToValue( paragraphs ) | ||
} ) | ||
} /> | ||
<footer> | ||
|
@@ -46,11 +76,11 @@ registerBlock( 'core/quote', { | |
}, | ||
|
||
save( attributes ) { | ||
const { value, citation } = attributes; | ||
const { content, citation } = attributes; | ||
|
||
return ( | ||
<blockquote> | ||
{ value && value.map( ( paragraph, i ) => ( | ||
{ content && content.map( ( paragraph, i ) => ( | ||
<p | ||
key={ i } | ||
dangerouslySetInnerHTML={ { | ||
|
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.
Returning
null
above is also an error (no transformation found), we should be consistent.In the same time, I'm wondering if we really need to throw specific errors. I don't see any use case where we'd want to perform different actions depending on the error. Should we show this error somewhere in the UI? I don't think so, it's not relevant for the user I think.
Note that the
transforms
API is not used for block switching only. If we introduce new returns values like these, we'd want to handle them in all "clients" see #457Also, I think we should perform the transformation even if we have data loss (we should limit the data loss) because the user explicitly asks for the transformation, so it's not a surprise for him to get its content changed a bit. For example when switching from a text block to a heading block, I'm not agains concatening with spaces the different paragraphs. If we reject the transformation, this means backspacing from a text block to a heading won't work either.
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.
What would you suggest returning instead of
null
? To me this makes sense because it is a generic failure case which doesn't have specific meaning to the user (something went wrong in the code).I'll address the rest of your comments below.