Degraded editor performance during file compression

Bug report

Packages affected

• sandpack-client
• sandpack-react

Description of the problem

Hi! First off, thank you for this amazing tool 🙏 It has been an extremely simple process to get up and running with an embedded code editor, which is incredibly awesome.

The issue I noticed is that when using the suggested strategy for using private NPM packages, I’ve noticed that if the package is large, it can cause a really notable lag when trying to use the editor (see the video below). From what I can tell, this happens because when the files change, it kicks of a useEffect that compresses the files.

With smaller files, that makes a lot of sense and allows the ability to open in a codesandbox anytime with little delay, which is awesome. However, it seems that if this is the go-to strategy for using private packages, it may benefit from having a way to avoid this behavior for larger packages. The options I thought of were:

1. Add an option in the options or customSetup to remove the “Open in Codesandbox button”
2. Make the compression an asynchronous process that does not block the main thread (and a loader can show in the button till it’s complete)
3. Implement a caching strategy to avoid re-compressing large files (maybe detect which file changed and only re-process them?)

I’m not familiar enough with the package to know which of these, if any, are viable, but option 1 seemed like it’d be relatively straight forward compared to the others.

https://user-images.githubusercontent.com/46691367/163629990-c00a8e2e-5109-423a-9f68-37ce532ce459.mov

(Apologies if the video is unclear, but anytime that typing stops, it’s because it’s lagging)

Note: I tried running with autorun: false and recompileMode: 'delayed' to try to change the behavior, and they might have helped a little bit, but the issue persisted.

What were you doing when the problem occurred?

Editing a file while using a very large UI library package as a dependency.

What steps can we take to reproduce the problem?

• Use this strategy to add in a LARGE custom package. Unfortunately mine is private or else I’d set up an example using it, but it’s a 2.3MB bundle comprised of a relatively large UI component library.
• Attempt to edit a code file that imports that library

Your Environment

Software	Name/Version
Sandpack-client version	0.15.2
Sandpack-react version	0.15.2
Browser	chrome / 100.0.4896.88
Operating System	macOS / 12.3.1

Apologies if this a duplicate issue or there’s already an easy way to go about this!

[danilowoz]

Addressed here https://github.com/codesandbox/sandpack/issues/448

Thanks @joebingham-wk once again

[joebingham-wk]

Those are good questions. I only know how to use web workers conceptually, so it’d be really interesting to see if they do work here.

Thank you for giving me the chance to take a stab at it, but I’ll let ya’ll decide when the best time to make this change is! The initial solution of exposing showOpenInCodeSandbox works great for my use case, so from my perspective there isn’t a hurry to try the web worker approach.

It’s an awesome project though. I’ll keep the project in mind when I have capacity to do some OSS contributions!