Gutenberg: Reusing TinyMCE instances
If we're going to have multiple TinyMCE instances (one or more for each block), it might be good to try to reuse one for all of the fields. The instance could be attached to the field that is currently focussed, undo levels could be disabled etc. Creating new blocks would also be a bit faster.
ellatrix
All 9 comments
@spocke @Afraithe maybe they should be using our inline mode?
androb
on 28 Mar 2017
We are using the inline mode :)
ellatrix
on 28 Mar 2017
Ha :) sorry. I thought we handled this sort of reuse of editors automagically. It is possible that it is something we did in Textbox.io and haven't yet got into TinyMCE.
abovemypaygrade
androb
on 28 Mar 2017
Is this more or less addressed with the Editable component?
jasmussen
on 31 May 2017
@jasmussen No, they're all separate instances. See also https://github.com/WordPress/gutenberg/issues/919#issuecomment-304655822.
ellatrix
on 31 May 2017
@iseulde - is this still an issue? It would be good to understand a bit more about what you are looking for here. Feel free to ping me on Slack.
androb
on 5 Oct 2017
The idea was to only have one instance of TinyMCE and when the selected Editable changes, move the instance to the new Editable, discard undo levels etc. to avoid having tons of instances around. This may be something we can explore at a later stage to improve performance. Not sure how much it would improve that though.
ellatrix
on 11 Oct 2017
This may still be an interesting experiment to try to speed things up. I'm noticing some really big delays when enter is pressed on iOS and a new instance needs to be created. Theoretically this will create one instance per setting variant (most blocks will have the same setting, variants include list and table), and when a new field is focussed it will attach to that field (reset target node, purge undo levels, trigger nodeChange etc.). When enter is pressed, the field and editor will be available immediately. This may also be beneficial for big posts where now an instance needs to be created for each editable field. When we reuse instance, we can just load the content with contentEditable and that's it.
ellatrix
on 31 Jan 2018
As we approach the close of phase one, lets close this for now. We can always look at this in a later stage if we do want and reopen.
karmatosed
on 22 Jul 2018
Related issues
mhenrylucero
路
3Comments
wpalchemist
路
3Comments
davidsword
路
3Comments
spocke
路
3Comments
aaronjorbin
路
3Comments
Most helpful comment
This may still be an interesting experiment to try to speed things up. I'm noticing some really big delays when enter is pressed on iOS and a new instance needs to be created. Theoretically this will create one instance per setting variant (most blocks will have the same setting, variants include list and table), and when a new field is focussed it will attach to that field (reset target node, purge undo levels, trigger
nodeChangeetc.). When enter is pressed, the field and editor will be available immediately. This may also be beneficial for big posts where now an instance needs to be created for each editable field. When we reuse instance, we can just load the content withcontentEditableand that's it.