Third party libraries
There's a huge amount of third party libraries available in the React ecosystem, and sometimes you'll find it necessary to use some of them in your shop. Before you start implementing them in your shop, there's some questions you should ask yourself.
Is there already a way to do this in?
In some cases, we might have already solved your problem, or have chosen an alternative dependency that does the same thing. Make sure that your need isn't already fulfilled in the framework, either in the shop template or in the core or ui packages.
If there's a solution that almost supports your needs, but that doesn't go all the way, please add an issue in Gitlab for it and we'll take it up for consideration.
How will this affect my bundle size?
This can be quite tricky to measure accurately, but there's some good tools to use.
Package weight
BundlePhobia is a tool that tells you the actualy size of a package. This tells you what footprint this package will put in your shop. Just type the package name and you'll see a breakdown of the package composition and bundle size. All packages should be carefully considered, but especially if it weighs in at over ~10 kb gzipped.
BundlePhobia will also show you alternative packages and show their bundle sizes.
Tree Shaking
BundlePhobia will also highlight when a package is tree-shakeable. This means that the package will allow you to import only the parts you need, which will result in a much smaller bundle. For example, the lodash-es package is tree-shakeable. This means you can pull in only what you need:
import truncate from "lodash-es/truncate";webpack-bundle-analyzer
We've included webpack-bundle-analyzer, which is a nice utility to help you analyze your builds. To activate it, build your store with the following command:
yarn build:analyze
A graphical UI is opened when the client build is done, where you can visually analyse how much space every file in your bundle uses.
How does this affect the performance of my shop?
This might be harder to measure, but is very important in order to keep your shop fast and to keep a good conversion rate. Many times there's a correlation between bundle size and performance, where a small package generally performs better and faster than a bigger one.
We do run Lighthouse performance tests on the start page in the CI pipeline, so if you want to try out a new third party dependency, you can implement it on the start page in a branch and see if it affects the resulting score.
Is this package well maintained?
Another good indicator of the quality of a package is the amount of open issues on its repository. It's a good idea to scan over them before including a package in your project. You can find the repository by searching for the package on npmjs.com, which will link the package's repository.