Performance issues when nesting multiple components in a slot

[FedericoBonel]

Description

Updating a component's prop that uses a slot with multiple nested components causes severe lag in the editor. This is reproducible in the demo.

Environment

• Puck version: 0.19.3

Steps to reproduce

1. Navigate to the Puck demo app: https://demo.puckeditor.com/edit
2. Drag and drop a Grid component into the editor
3. Populate the grid with multiple Card components (it depends on hardware, but more than 60 to 80 should start to show the problem)
4. Change the "gap" field in the grid

What happens

The editor becomes sluggish and unresponsive when modifying fields in the parent component with the slot that has multiple children.

What I expect to happen

Changes to any component's fields should apply smoothly, regardless of the number of children rendered in their slots.

Additional Media

https://github.com/user-attachments/assets/d7331980-ceba-4248-8f27-ec615815439a

[ojj1123]

To make templates with the high degree of freedom, it's necessary to use Slot pattern combining the component config we define. In my company, we use Puck (thanks for the great works 👍) but there are some VoC struggling with the performance issues if they have lots of inserted components. I was wondering if you could solve this problem :)

[FedericoBonel]

Hey @ojj1123! We're currently working on what we believe is a related issue — though not the same one — specifically some problems we've identified with array fields. You can check out the pull request here: https://github.com/puckeditor/puck/pull/1213

[do4Mother]

I also experienced the same thing, when migrating to the Slot Component , the fps suddenly dropped to 1 fps.

[benlife5]

Adding on that we've experienced some additional slowdowns as we've switched to slot-centric components and our data payload has increased in size.

We see it mostly when loading initialHistory -- we get the Puck spinner for a couples seconds and some console logs like [Violation] 'message' handler took 1398ms

https://github.com/user-attachments/assets/df6eaced-b12b-4159-b088-3e6e81d2b3f2

For reference, this data payload was 257kb and included multiple components that have deeply nested slots (example)

[jeroenrinzema]

We’ve noticed components are frequently rendered even when fields haven’t been updated. Another issue is that for nested components with editable content, focus loses when multiple nested components are present. I’m trying to reproduce it but haven’t yet pinpointed the problem.

[tigfamon]

Hi guys! Firstly, thank you for providing such amazing tools!

I'm working on integrating the Puck editor into a low-code platform and have encountered some performance-related issues. The key concern for me is why child components are remounting when I change a field property in the parent component.

I've published a reproducible demo - https://codesandbox.io/p/sandbox/s9sq9p. In the demo, you can see that when we change the gap property in the Flex component, the Heading component remounts every time. Considering that in a real-world scenario, the Heading component would be more complex and resource-intensive, changing some parent's properties becomes a very expensive operation.

I also tried using the deprecated approach with Dropzones and couldn't reproduce this issue there. For now, I've had to fall back to the deprecated approach.

I was wondering, are there any updated regarding these performance issues?

[FedericoBonel]

Hey @tigfamon and @jeroenrinzema,

First, thanks for the feedback! We've been working on identifying these issues and now have a much clearer understanding of them.

Regarding the component remounting issue: I believe this is the same one @jeroenrinzema mentioned about components being frequently re-rendered. This happens when you change the field of a parent, when you do, all the subtree gets remounted. The root cause is a bug with slots, as you pointed out. We now know where the problematic code is, and we're currently working on finding the best solution to fix it. And yes, you're right, this doesn’t happen with DropZones.

We've also identified some other related issues and will be addressing those as well.

As for the contentEditable losing focus, I haven’t observed that behavior yet. If you're able to pinpoint when it happens, that would be super helpful!

Either way, thanks for the detailed feedback 🙏