Poor performance while editing large files

[sondrele]

Describe the bug
I have a file with a bunch of messages, the model is essentially the same config as for the authors in the netlify-cms dev-test.

While editing a message, the performance is very poor and results in a very janky UI.
I'm assuming this is due to the onChange handler being called on every edit, which results in validation, and re-rendring of the entire component tree (please correct me if I'm wrong, I do not have a good overview of the internals in netlify-cms).

If my assumption is (somewhat) correct I propose storing the values while editing locally in the widgets instead of calling the onChange handler on every event, and only call the onChange handler in an onBlur handler instead.

To Reproduce
The easiest way to reproduce is to start the dev-test locally with a lot of authors manually configured:

1. Clone my fork: https://github.com/sondrele/netlify-cms
2. In the cloned directory: yarn && yarn develop
3. Navigate to: http://localhost:8080/#/collections/settings/entries/authors
4. Start editing the name of the first author

Expected behavior
Editing content should not have that kind of performance problems.

Screenshots

I've included a gif of what it looks like when writing. Not sure how obvious it is from the video, but I can testify that I'm hitting the keys way faster than the characters appear :)

Applicable Versions:

• Netlify CMS version: 2.3.3
• Git provider: any
• OS: Linux
• Browser version: Firefox 65

• Node.JS version: 11.1.0

CMS configuration
Here: https://github.com/sondrele/netlify-cms/blob/master/dev-test/config.yml
Authors data: https://github.com/sondrele/netlify-cms/blob/master/dev-test/index.html#L42

Additional context

[erquhart]

Calling onChange with every change should be fine, it's calling onChange on the other 116 messages that aren't being edited that's likely causing this.

[lfeddern]

@sondrele did you ever find a solution for this?

[lfeddern]

@erquhart would you be able to point me in the right direction in the repo and I will try and fix

[erquhart]

The proper fix here is pretty deep in the CMS - I'm expecting we'll start having all widgets maintain their own state - propagating changes up, but not receiving their value through props. This is effectively happening for some widgets, like markdown and list, but values are still passed down the tree and have to be read and run through shouldComponentUpdate() for every widget. This assumption does require some testing, but I'm fairly certain it's the path to take.

This needs proper planning between the implementer(s) and maintainers , so that's the first step if you're interested in digging in.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[erezrokah]

Closing this in favour of #3415

[lupelius]

this is still happening I wouldn't have closed it, neither this one or #3415 seems to be fixed, my project needs a massive refactor for working around this putting each entry in its own file, when can we expect a fix please?

[erezrokah]

Hi @lupelius, we can track this issue under #3415.
Keeping duplicate issues open just makes it hard to address them.

The CMS is a community based project, so we would love if someone could contribute a fix for this.