This post is by Hashrocket from Hashrocket
Click here to view on the original site: Original Post
While building a large React SPA, we reached a point where we needed to cut
down the bundle size a bit. We identified some candidate dependencies —
packages that were being used sparingly but had a large footprint on the
bundle. We then found some alternatives to those packages with a fraction of
the bundle size. We just needed to be sure that these packages could do what
we needed them to do. This is where CodeSandbox
Under the Dependencies tab in the File Editor section is a big, blue
button — Add Dependency. That button pops open a search modal that allows
you find packages from the npm registry. Start
day.js and it will quickly show up as one of the results. Click on
it and it will be added as a dependency of the project.
We can now give
day.js a test run in this isolated environment. We can
compare what we are seeing in the docs with what we are able to get working
in this sandbox environment. We were primarily using
formatting dates, so we went to work reproducing our formatting utilities
This not only gave us confidence that
day.js could do the things we needed
it to do. It also gave us a tangible artifact that we could pass around to
others on the team to get buy-in on the change. Once you save a CodeSandbox
instance, you get a unique URL that you can pass around to anyone.
Now that we were satisfied with
day.js and had buy-in from the rest of the
team, we could set out to create a pull request that would make the switch.
CodeSandbox has become invaluable to many parts of my workflow. But I've
especially come to depend on it for evaluating my dependencies.
Cover photo: Wolfgang Hasselmann