-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
#10358 Introducing a downcast helper elementToStructure with reconversion support #10466
Conversation
…erting elements (text nodes are not supported).
Things to verify manually (cc @ckeditor/qa-team):
Missing (cc @niegowski):
Asking @scofalik to review this:
|
Added. |
} ); | ||
|
||
const convertedViewElement = mapper.toViewElement( element ); | ||
convert( range, markers, writer, options = {} ) { |
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.
Do we need to pass markers here or can they be taken from range
(range.root
to be precise). I am not sure if RootElement
has a reference to Model
instance. Wouldn't it be nice if you didn't have to evaluate those markers on your own (like in data processor)?
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.
The problem there is for example with Title
plugin that for getBody()
finds only intersecting parts of markers.
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.
And in DataController
we pass there only _getMarkersRelativeToElement
.
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.
Couldn't we evaluate it in the dispatcher? Relative to range in this case, I guess, or let passing range or element to the dispatcher?
Not sure how Title
works.
@@ -335,21 +217,20 @@ export default class DowncastDispatcher { | |||
convertSelection( selection, markers, writer ) { |
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.
Same here, would be nice if we could skip markers
parameter ;).
TBD:
I'll ping you f2f about this. None of this is a blocker for merging the PR. |
} | ||
} | ||
|
||
return [ node ]; |
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.
Why null
or single-item array instead of true
or false
?
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.
I see this function is used as default parameter later in the code. Will there be cases when the user will write this function on their own, and then the function would return bigger arrays?
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.
Or is this for future purposes? Or artifact from the past :)
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 was for future purposes but in a recent spike, I found a better way to handle it. In the next PoC it's true/false ck/10294/reconversion...ck/10381-imperative-reconversion
return false; | ||
} | ||
|
||
return events.every( event => consumable.consume( node, event ) ); |
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.
I think that forEach()
+ return true
would be more clear.
// @param {module:engine/model/element~Element} element | ||
// @param {Map.<module:engine/view/element~Element,Array.<module:engine/model/node~Node>>} slotsMap | ||
// @param {module:engine/conversion/downcastdispatcher~DowncastConversionApi} conversionApi | ||
// @returns {Function} |
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.
I am missing here at least a sentence about the parameter which the function can take.
if ( options.reconversion && viewChildNode && viewChildNode.root != viewElement.root ) { | ||
writer.move( | ||
writer.createRangeOn( viewChildNode ), | ||
mapper.toViewPosition( ModelPosition._createBefore( modelChildNode ) ) | ||
); | ||
} else { | ||
conversionApi.convertInsert( ModelRange._createOn( modelChildNode ) ); | ||
} |
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.
Clarification needed.
- Are there two modes because this function is sometimes used for the "first insertion" and sometimes for reconversion?
- Do we check
viewChildNode
when there'sreconversion
flag because of text nodes? - Why do we check roots?
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 for cases when reconversion is triggered by adding/removing child nodes. The old view elements are restored and only the added child is converted.
- We want to restore old view elements only for reconversion and not while the initial insert.
- To make sure that that view element is not already added to the view structure.
I like the API, I like or am neutral with almost all of the changes. Other than what I commented:
Also, maybe you already considered that, but the sample with table is still a bit complex. Maybe slots could be named, so that if there is anything to put in the slot, a proper view element would be created automatically?
Instead of:
I think it looks cool that you can create "view element" that takes callback instead of children ;). However it may be confusing (if you don't know how slots work, you may think that you will get an empty element, OTOH, you might want to have an empty element and in such case you need to go with the "regular way" to create elements). |
This would force to wrap elements with a container element (
In such case the slot does not need a wrapper, view elements should be inserted directly into the |
I never meant this should be the only way to create slots.
|
Suggested merge commit message (convention)
Feature (engine): Added
DowncastHelpers#elementToStructure()
downcast helper with reconversion support. Closes #10358.Feature (engine): It's now possible to trigger a nested conversion while downcasting an element.
Other (engine): The
DowncastDispatcher#convert()
method introduced as a replacement to previously usedconvertInsert()
. The new method handles not only nodes conversion but also markers.Internal (heading): Code adjusted to changes in
DowncastDispatcher
API.Internal (html-embed): Code adjusted to the removal of
triggerBy
conversion option.BREAKING CHANGE (engine): The
DowncastDispatcher#conversionApi
property is no longer available. The instances ofDowncastConversionApi
being created at the start of conversion.BREAKING CHANGE (engine): The support for the
triggerBy
option for downcast helpers is removed and replaced with the newelementToStructure()
options.Additional information
This PR removes support for previous reconversion implementation and it's a part of an epic to reintroduce it in some downcast helpers.