RichText: Remove focusPosition state #7651
Conversation
aduth
added
[Feature] Rich Text
| this.setState( { formats, selectedNodeId: this.state.selectedNodeId + 1 } ); | ||
|
|
||
| if ( this.props.isViewportSmall ) { | ||
| let rect; |
There was a problem hiding this comment.
Why is this needing to be calculated at every node change event? Do we need to scroll every time on that event? Cc @mcsf.
There was a problem hiding this comment.
It almost certainly doesn't need to be. There's definitely room for improvement here, but I considered it outside the scope of the current task.
There was a problem hiding this comment.
Sounds good, I like the smaller PRs :)
There was a problem hiding this comment.
I'm sure there's room for improvement. When we looked in #5769, there was no proper way to detect when the insertion of a character fills the whole width of a text container and forces the caret into a "new line" (a different height in the same container). 'nodechange' is definitely too generic, but per the comment, on nodechange we can work with the finalized TinyMCE instance and scroll to proper position.
There was a problem hiding this comment.
Perhaps the same kind of reasoning we're seeing in this PR (let's manage this ourselves with our vdom abstraction so as to batch positioning writes and reads) can be applied to the caret-tracking scrolling feature.
|
The only thing I can find here is that the position is not updated after inserting a link without selection:
But that certainly better than current master:
|
aduth
force-pushed
the
remove/rich-text-focus-position
branch
from
797afe9 to
c3fe6ce
Compare
| const selection = window.getSelection(); | ||
|
|
||
| // Get position relative viewport. | ||
| const rect = getRectangleFromRange( selection.getRangeAt( 0 ) ); |
There was a problem hiding this comment.
Though improbable in the context in which we expect to use this component, should we guard against IndexSizeError by checking selection.rangeCount > 0 first?
There was a problem hiding this comment.
Though improbable in the context in which we expect to use this component, should we guard against
IndexSizeErrorby checkingselection.rangeCount > 0first?
Yep, seems very reasonable. Updated in the rebased 6eed870.
| this.setState( { formats, selectedNodeId: this.state.selectedNodeId + 1 } ); | ||
|
|
||
| if ( this.props.isViewportSmall ) { | ||
| let rect; |
There was a problem hiding this comment.
Perhaps the same kind of reasoning we're seeing in this PR (let's manage this ourselves with our vdom abstraction so as to batch positioning writes and reads) can be applied to the caret-tracking scrolling feature.
editor/components/rich-text/index.js
Outdated
aduth
force-pushed
the
remove/rich-text-focus-position
branch
from
c3fe6ce to
6eed870
Compare
Closes #6640
This pull request seeks to optimize the
RichTextcomponent to avoid needing to keep afocusPositionstate. This state was used exclusively for the positioning of the link popover overlay, and was calculated on everyNodeChangeevent in TinyMCE (which occurs fairly frequently). Its use ofElement#getBoundingClientRectwould also trigger browser relayout, thus being prone to layout thrashing (source). This revised implementation introduces a new component which is responsible for positioning itself relative the current selection at the time of its own mount. Therefore, it's only calculating its position when the link overlay is actually used.Testing instructions:
Verify there are no regressions in the display of the link format popover.
This was challenging to implement automated tests for, since JSDOM supports neither
window.getComputedStylenorHTMLElement#offsetParent. End-to-end tests may be wise for link additions, but the specific behavior here is relevant mostly to visual appearance, and we currently have no precedent for visual regression testing (though it may be worth exploring).