Framework: split block logic out of RichText (part 2)#16309
Framework: split block logic out of RichText (part 2)#16309
Conversation
26f1136 to
f8d5774
Compare
a289478 to
f2342e5
Compare
beeeaf8 to
92532b2
Compare
jorgefilipecosta
left a comment
There was a problem hiding this comment.
Awesome work here @ellatrix, I did not find any regressions, and these changes seem to put the API in a better direction.
I left some comments but I don't think there are blockers.
| let adjustedOnChange = originalOnChange; | ||
|
|
||
| // Handle deprecated format. | ||
| if ( Array.isArray( originalValue ) ) { |
There was a problem hiding this comment.
Should we add a deprecated call, to warn developers that a deprecated format is being used?
There was a problem hiding this comment.
Good point. I believe a warning is logged from the blocks api package when this type of source is used, but I will test again to confirm.
There was a problem hiding this comment.
As far as I can see, the deprecation were removed and never reintroduced. In other words, what @youknowriad suggested has never been done: #10439 (comment). Let's do this in a separate PR.
|
Thanks for the review @jorgefilipecosta! :) |
|
The base RichText is again under a 1000 loc! 🎉 |
Description
This PR splits block related logic out of RichText into the RichText wrapper for blocks.
The RichText wrapper (to be used in blocks) now implements:
*to list etc.)Also moves format relate logic to the format library:
`rule to transform to<code>.How has this been tested?
E2e tests. Everything should work as before.
Screenshots
Types of changes
Refactoring.
Checklist: