Admin dashboard slows down significantly after rendering large array
Hi there! I have a collection with an array field that contains 13 fields per row. The array usually contains 100 to 200 rows and there are also
conditionfunctions. The problem is that Edit View for docs from this collection is really slow because there is a lot to render and calculate.
My only idea is to make this field hidden using
admin: hiddenand build a custom one with virtualization. The main requirement is that Editors have the possibility to edit any field in any row, so I'll have to handle updates manually... has anyone encountered such a problem before and have a better idea?
Thanks!
so we have done some significant performance optimizations to be able to handle thousands of fields rendered at once, but it seems like you are hitting the upper limit of what is possible to render
Does this boil down to a limitation of the DOM? Could a virtual list component be a solution?
well, honestly yes
but if he has 13 fields per 200 rows, that's 2600 field components
that will melt any React app
Ah that's true
Especially if the fields types are all varying
i will say that we do lots of fancy stuff, like
notrender the fields unless they are within 2000 px of the viewport
so this should optimize a lot of that
@svn__ if you can create a minimally reproducible repo, we would be happy to look into this, because there is a chance that our performance enhancements are just not working for some reason
although if possible, you may want to just try and reimagine your content model in general - maybe have each array row render a single relationship field, where the editing of each row is done in the "drawer" UI instead
I'm afraid they are working correctly, I've already noticed this when scrolling. I'll prepare a repo with reproduction for you, just give me a few minutes. I'll also try to reimagine model for this collection before going with a custom field
it may also be because of how many conditions you have
That may be the best approach, modify the data structure first if possible
in the future, we want to create an alternate, higher-performance conditions workflow where you can subscribe only to the fields that you want to "watch" for changes
if you have lots of conditions, that could be the reason why your performance is suffering
I keep meaning to check out:
https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility, and other draw-related CSS optimizations. Though, this may be specifically the amount of nodes
i think it's probably related to react rerendering so many things
not the draw performance itself
Ahhh
Yep, I think so too
and it probably won't be a problem with a custom field that renders the whole list as paragraphs and has just
editbutton for each entry
In terms of conditions, I've commented them out and prepared a very simple reproduction. Just need to create a repo for this, will come back with the link soon
beautiful
thank you!
here is the link to reproduction:
https://github.com/svntime/payload-large-array(based on reproduction-guide from Payload's repo so
yarn dev _communityshould be enough)
it's simplified and doesn't work that bad but mine collection config is a bit more complex 😄 I want to build a "report" from the race - each rider has multiple scores and relationship field to Riders collection
and it works like on the repo above with 4x CPU slowdown from devtools
scrolling the list is fast but when you try to open the row or save the changes, it takes some time
and as mentioned before, it's a lot to calculate for CPU and I understand why it works like that
I'll try to reimagine the model or just build a simple renderer component for the array (with edit form as a modal for each row)
Forgot to mark this one as answered. Things got better after upgrading to 1.10.1 and as I saw in the comments here:
https://github.com/payloadcms/payload/issues/2747, it may get even better in the future. Great job guys and thanks!
woah, nice!
thanks for the update @svn__
Continue the discussion in Discord
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.