RichText Trigger onChange on input#4955
Conversation
|
See: #2758 (Particularly bits about undo history) |
18e97c2 to
571d61d
Compare
|
I'm currently rebasing a WIP branch that does the undo signalling with a buffer in the history. I'm also leaving out selection now since it would make it more complex. I feel like we should fix undo together this PR. |
blocks/rich-text/index.js
Outdated
There was a problem hiding this comment.
I forgot to add content = '' here 🙈
e6af488 to
87ca673
Compare
|
So from my testing, performance is good enough here but I'd appreciate that other people try it to confirm Edit: Erratum: On long post it's not good at all, needs further investigation |
| this.getSettings = this.getSettings.bind( this ); | ||
| this.onSetup = this.onSetup.bind( this ); | ||
| this.onChange = this.onChange.bind( this ); | ||
| this.throttledOnChange = throttle( this.onChange.bind( this ), 500 ); |
There was a problem hiding this comment.
If we can, I'd love if we would avoid throttling. Case in point: We're not cancelling a scheduled change when the component unmounts.
There was a problem hiding this comment.
Yep, if the performance fix is enough, I'm fine dropping it.
There was a problem hiding this comment.
I tried dropping it but I think performance-wise it's slightly better if we keep it
There was a problem hiding this comment.
It seems like it always dispatched change when I type the first character. Should we wait until 500ms passes instead?
|
@youknowriad I created a branch off of this one which includes an iteration on https://github.com/WordPress/gutenberg/tree/try/weak-map-cache See: aduth/rememo#1 |
|
@aduth Awesome, I'm not seeing any performance issues any more 👍 On the performance side, maybe instead of using |
15fa35c to
efff741
Compare
|
Rebase this with the changes from #5002 it seems better now. |
|
@youknowriad, see https://github.com/WordPress/gutenberg/pull/5002/files#r167532619, can we bring the polyfill as part of this PR? |
|
|
||
| content = renderToString( content ); | ||
| this.editor.setContent( content ); | ||
| setContent( content = '' ) { |
| if ( this.editor.isDirty() ) { | ||
| this.fireChange(); | ||
| } | ||
| this.savedContent = this.state.empty ? [] : this.getContent(); |
There was a problem hiding this comment.
@aduth - should we extract [] to its own shared variable to ensure we have always one variable reference to compare with ===? I wanted to double check - you know better all those perf bits. It might not make any sense in this context :)
| this.props.value !== this.savedContent && | ||
| ! isEqual( this.props.value, prevProps.value ) && | ||
| ! isEqual( this.props.value, this.savedContent ) | ||
| this.props.value !== this.savedContent |
There was a problem hiding this comment.
It seems like shallow compare is enough here.
|
|
I'd be inclined to omitting the I'll try to take a pass at these today (non-blocking). |
gziolo
left a comment
There was a problem hiding this comment.
I tested in enough. Let's merge it and continue in the follow-up PRs as discussed 👍
| this.updateContent(); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Removed line break by accident?
| return; | ||
| } | ||
|
|
||
| this.fireChange(); |
|
I don't know, this was part of one of your commits, I can restore :) |
|
@youknowriad I think I removed that there assuming changes would be in sync all the time, but with the throttle that wouldn't be the case? |
|
Noting that in the course of writing a post with a single paragraph containing only 32 words, I accumulated 71 copies of editor state via undo history (and that this will only grow over the course of writing a post in the same session). |
|
Something revealed by this change: Should we be debouncing autosave instead of throttling? It feels as though it saves much more frequently now, since it can occur many times while typing within the same paragraph block. Debouncing isn't great either, since just because I don't stop typing for X amount of time doesn't mean the post should never save during that time. Or maybe the autosave should just be made less frequent than every 10 seconds? |
| @@ -149,6 +151,7 @@ export class RichText extends Component { | |||
| editor.on( 'BeforeExecCommand', this.maybePropagateUndo ); | |||
There was a problem hiding this comment.
Did we test to see how TinyMCE's undo history interacts with our own?
- Are we calling
onChangewith the correct value after TinyMCE finishes undo? - Should we be bypassing TinyMCE's undo altogether (also preventing it from accumulating any history)?
|
@aduth I don't mind if we save frequently, but it is quite visually distracting ATM. Sounds like it need to be more subtle, similar to Google Docs. We also have to make sure we don't just pile these changes up as revisions, instead we should maybe reuse the last revision and only create a new revision on a user action or at least way less often (each revision is a post in the DB). |
Yeah, this is an ongoing issue unfortunately: #3656 |



This will be necessary to achieve #4951
It also fixes some issues while the save draft link doesn't show up until we focus out of the component.
It may introduce a difference in a way undo/redo works but I believe we should handle those consistently (it's not the case right now, RichText triggers and undo state per word while PlainText it's per character). I'm thinking we could use the
withHistorya Reducer enhancer to group similar changes into one undo level.Testing instructions