Attempting to load Redux devtools freezes the page

[nylen]

Self explanatory I think. We should git bisect to figure out when this started happening.

[BE-Webdesign]

I think the dev tools are running out of memory trying to parse and stringify the large body of text. If you cut the post content down to a smaller size the dev tools will run. This kind of has greater implications as well.

[nylen]

Nice find @BE-Webdesign, I can confirm that shortening post-content.js to only a single text block resolves this issue.

cc @mtias re starter post content being too long and consuming too much memory. It sounds like we need to do some memory profiling, and testing on lower-perfomance devices, because there are likely already some issues here even without Redux devtools.

Using real-world examples that are much longer and more complicated than the demo content, we should set up some stress/performance tests with very long content as well. Probably OK for something like our full-content tests, but I'm not sure if we want to run them on every build.

cc @iseulde, I wonder if something like #847 would also help with this.

[mtias]

@nylen definitely, it's time to start looking at how to profile and test different post sizes. Do you want to look into how we could set this up? I have a few real-world examples from Matt of posts that are quite long and complicated, and which struggle in tinymce already.

I'm also a bit concerned with validating individual block shapes through schemas (#914) because of how expensive things could get.

[ellatrix]

I wonder if something like #847 would also help with this.

@nylen I'm unsure about the impact. Something I have in mind that we could try is just adding the contentEditable to the Editable, but either only initialise it once it receives focus, or initialise one instance with the same settings and attach that to focussed Editable. A condition for this is that we don't rely on TinyMCE's parsing and validation and that we can just set the "raw" content. Removing this parsing alone should also improve initialisation speed.

I have a few real-world examples from Matt of posts that are quite long and complicated, and which struggle in tinymce already.

@mtias Could you share those?

[nylen]

Do you want to look into how we could set this up? I have a few real-world examples from Matt of posts that are quite long and complicated, and which struggle in tinymce already.

Sure, can you share those examples with us somehow? We'll probably want to adapt them to contain blocks. I'm also aware of a couple others inside a8c that would need sensitive information removed.

I think something like test/fixtures but with memory/speed profiling (and without running on every build) would work well.

[nylen]

I'm also a bit concerned with validating individual block shapes through schemas (#914) because of how expensive things could get.

This seems true of any way of doing the things listed in #914 (mainly future enhancements). I think it is better for us to handle this complexity in a reusable way than to push it onto plugin authors.

[aduth]

On a hunch I dropped the list blocks from post-content.js and the DevTools load without issue. It's not a general issue of content size, but rather how we're setting into attributes (tracked by Redux state) the list block's TinyMCE instance.

It opens a question about the sorts of values we want to allow to be set into attributes. Should they be non-complex values only (numbers, strings, booleans)? How do we enforce this, or do we even want to? What alternatives do we propose instead (in this case, perhaps in block component state).

Still not totally clear on why the TinyMCE instance specifically causes the page to crash.

cc @EphoxJames

[youknowriad]

Oh! I missed this, yeah we should assume that all the attributes we pass to setAttributes are attributes to be serialized (in the content or the comment), if we need complex attributes like this, we should use Component's local state. (Moving the controls to the edit function helps here.