Improve rendering performance

[chrisvxd]

Rendering performance can sometimes be slow, with re-renders occurring whenever the app context changes in all components that depend on it.

This is particularly notable when changing field values, which makes multiple changes to the app context (due to advanced features like field resolution, data resolution, etc). This is somewhat masked by a 50ms debounce. This works, but is inconsistent and causes a delay between user input and rendered output. 50ms may also be insufficient for some environments, and shows a significant different between dev and prod environments.

We should improve rendering performance and eliminate the use of debounce entirely.

Proposals

Better memoizing

Review current memoization and improve it wherever possible.

Split contexts

Break context down into smaller chunks.

Use use-context-selector

Make use of the use-context-selector library, which implements RFC119.

Replace app context with another state solution

Various state management libraries use selectors to avoid unnecessary re-renders.

Virtualize components

Virtualize component rendering when out of view.

Considerations

• Impact on usePuck hook
• New drag-and-drop engine #556 will change how items are rendered
• Stress testing #549
• DropZone component relies on context to know structure of tree, causing entire tree re-renders when any item in the tree changes. Would be solved by dropzone/slot field.

[IMythx]

i think react-tracked could help with context unwanted renders issue

[chrisvxd]

We might be able to go straight to use-context-selector

[Sarfraz-droid]

I shifted the nested context to storing objects in a global store. And rendering only the changed elements using zustand & useSyncExternalStore hook.

Could be something to consider but would require an entire state overhaul

Performance got improved by a lot. Could be something to consider

[chrisvxd]

@Sarfraz-droid State overhaul is definitely something we could consider as part of this. Did you do that via a fork? Would be interested to see it.

[Sarfraz-droid]

I tried out those changes mostly on a private repo. By cloning puck editor to libs in a startup. But I would be happy to detach the same in a fork. Will share as soon as it's done.

[FedericoBonel]

Hey @Sarfraz-droid! I kind of have the same issue you had before in: #549 (using a big data payload) would love to see how you approached this with virtualization and state overhaul.