search

decaporg / decap-cms

A Git-based CMS for Static Site Generators
https://decapcms.org
MIT License
17.77k stars 3.03k forks source link

Editing peformance is rough for large lists #3415

Open erquhart opened 4 years ago

erquhart commented 4 years ago

Describe the bug

When authoring in a large list, there are long pauses between keystrokes.

To Reproduce

  1. Go to https://www.netlifycms.org/admin/#/collections/updates/entries/releases
  2. Edit one of the list items

Expected behavior

Updates should be snappy.

Applicable Versions: CMS 2.10.31

Additional context

This is a long known issue, just needed to be documented. shouldComponentUpdate is currently set to always update on lists because the list widget doesn't know if it's children require updates from whatever state change is coming down.

I'm certain we can be smarter about this logic. If we can get a quick easy win, let's at least prioritize it. If it's likely to be a bigger lift, let's just get some thoughts down and prioritize later.

An improvement here will likely improve perf across the editor, or at least pave the way for general perf improvement.

ottozaiser commented 4 years ago

Hello! Do you guys recommend a workaround about this issue?

lupelius commented 4 years ago

this is still happening, neither this one or #2009 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?

magomimmo commented 3 years ago

Hi @erezrokah, is there any news on this issue? We're very close to deliver the project to the client, but this issue is so severe that will stop the delivery. If I remember well you're working on it.

My best

erezrokah commented 3 years ago

Hi @magomimmo, no progress so far. I had to shift focus to other issues.

magomimmo commented 3 years ago

Thanks @erezrokah, we'll see what we can do about it. Eventually we'll ask you some suggestions on the best way you think it's needed to fix it and what are the minimum requirement from you're side.

stevenpeniche commented 3 years ago

@erezrokah @erquhart wondering if there's been any progress made on a fix for this?

erezrokah commented 3 years ago

Hi @stevenpeniche, no progress yet. However, we would be happy to accept a contribution for this

martinjagodic commented 2 years ago

Did anyone investigate, is the source of this issue in the Github API, or is it more of a React/DOM problem?

erezrokah commented 2 years ago

or is it more of a React/DOM problem?

For this specific issue, I think ⬆️. See the shouldComponentUpdate issue in the original description.

herpster commented 2 years ago

Any news on this in 2022? I would like to use the CMS for a professional project, but the delay in input is so drastic that it makes little sense to pursue it further.

geotrev commented 1 year ago

I just filed #6563 because I didn't see this issue sooner. I see why, it's quite old!

Off the bat, it seems like a lot of child components are re-rendering even when their props are unchanged. Could a quick win here be to memoize each list item component so only "real" prop changes (e.g. changed field values) result in re-renders?

geotrev commented 1 year ago

6565

Here's a PR on an incremental fix to at least improve perf when object or list widgets are collapsed. I haven't had the time to dig through the redux store / overall component reconciliation strategy, but my basic thesis here is: if a module is collapsed/visually hidden, its content doesn't need to render, thus saving time on reconciliation.

There is a noticeable improvement on the kitchen sink example with this fix. If this seems reasonable I can go ahead and update tests/get it ready for approval. :)

geotrev commented 1 year ago

I must be the only one posting about this...

anywho, i went ahead and updated all the input components so they use a contained state variable for their values, and then their onChange handlers are debounced by 300ms.

This is probably not the most direct way to fix the performance issue but at least makes typing much nicer.

geotrev commented 1 year ago

I committed the dist file of the CMS in my fork so others can get this fix sooner, if needed. I don't plan to delete the fork/branch so until Netlify fixes it, have at it. If any of y'all have issues, feel free to post here.

https://cdn.jsdelivr.net/gh/geotrev/netlify-cms@hotfix/cms-perf/packages/netlify-cms/dist/netlify-cms.js

The exact changes in that dist are viewable in my fix PR (see above comment).

Alternatively, just fork my branch from this repo and update the above URL with your gh username. :)

https://cdn.jsdelivr.net/gh/USER_NAME_HERE/netlify-cms@hotfix/cms-perf/packages/netlify-cms/dist/netlify-cms.js

Use it just like the docs recommend in your admin/index.html file.

herpster commented 1 year ago

@geotrev I can't thank you enough, you are just awesome!

geotrev commented 8 months ago

Update: the PR to fix this issue was pinned by the decap team and is now stable as of latest master.

🤞🏻 if this goes in, it'll be a late but sweet christmas present!