5 Important Things To Check When Picking NPM React Libraries

As frontend developers, the NPM registry plays an integral part in our development. While it’s possible to create all features ourselves, there’s only so much time and resources available to do so. For this reason, we sometimes have to reach out for existing implementations made available by other developers.

This is extremely convenient as it saves us a lot of time and effort. But using an NPM library is more than just grabbing the first one off the shelf and installing it into your project. With over 1.3 million packages on the registry, the amount of choice available is enormous. But the quality can also be of varying degrees.

Learning how to dig your way through the forest of NPM libraries, determine what a good quality React library is, and what to pay attention to are essential skills as a React developer. To help with this, this article will go over the different aspects of an NPM library, how to asses it, and what it can potentially mean for you.

Library Size

One of the most straightforward aspects of a library is its size. When picking libraries, it’s quite often the first thing React developers check. And rightfully so, as the size of the library directly affects the amount of code that has to be shipped to the end-users. The bigger the library, the larger your project becomes, and the slower your application becomes for your users.

Fortunately, there are a lot of different ways to check for the size of libraries you’re trying to install. First of all, a library’s NPM page already displays the unpacked size of the library. But for most projects, this will not be a meaningful number. Instead, one can use Bundlephobia to view the bundle size of a library, when minified or gzipped. These will provide a more realistic image of how a library will impact your application.

Maintenance Activity

One of the major benefits to using NPM libraries is the open-source structure around it. Not only does it mean developers don’t have to create everything from scratch and risk potentially missing edge cases, but it also means that maintenance of the code can be left to the creators and maintainers of the library. This includes features, bug-fixes, and security issues.

For this reason, one of the most crucial things for a library is the activity of its maintenance. You shouldn’t expect the library to have a new pull request (PR) or release every day, but integrating an abandoned library without any active support can be a major red flag. This means that all of the maintenance burden falls onto you.

Once again, there are a lot of ways to check for the activity of a library and NPM already provides a lot of that information. The library’s NPM page will display the last time a new version was published and also list all the other releases. A healthy library releases new versions on a frequent and recent basis. Another way to gain a grasp of the library’s activeness is going through the PRs, commits, and discussions on the Github repository.

Proper Documentation

When you implement your own code, you can tailor certain structures, APIs, and decisions towards your own use cases. But when you’re working with a NPM library, this is rarely the case. Libraries have to account for all of their potential users and use cases, which means it’s likely that it’s implemented different from what you expected. This can make the library more difficult to use.

To address this, it’s crucial that libraries have a proper documentation on how to use their code. This could be about the API design, how to use the library, how to implement certain common use cases, and the list goes on. Making sure that the library you’re integrating has proper documentation will make your life significantly easier across the board.

Code Structure Compatibility

While this is very context dependent and potentially up to preference, the compatibility of the library with your project’s code structure can be important. It could be that your project implements React components in a more composable manner, but it could also be that you prefer to have one big component that accepts all the appropriate information as props.

An incompatibility isn’t necessary a dealbreaker in most cases. In certain very rare scenarios, the incompatibility can cause the library to be unusable in your project. But in most cases, it only means that more work and implementation is required from your side to integrate the library with your project. If you’re in the position to consider this aspect, then it will definitely save you some time.

Accessibility Features

When picking a React library, one of the things developers focus on a lot are the features. They have their set of requirements from either the designer or product manager and try to make sure that the library can cover all of them. While this makes perfect sense, an oftentimes overlooked aspect are accessibility features.

I won’t go in-depth about the entire topic of accessibility as that is not the scope of this article but it is an inseparable aspect to frontend development, even when it’s implemented through a library. In a previous article where I compared several libraries, it also played a decent role.

Unfortunately, there is no straightforward way to verify whether libraries have implemented the correct accessibility features and have done so properly. For this information, you’re basically reliant on the documentation written by the maintainers. Otherwise, the other, more manual option would be to dive into the code itself and compare the implementation to the W3C standards.

Final Thoughts

NPM packages are essential to our jobs as React developers. They’re convenient and can save us a lot of time and effort. However, picking the most suitable one isn’t always straightforward. Especially with over 1.3 million packages on the registry and varying degrees of quality.

To help with it, this article went over 5 aspects to NPM React libraries that you should pay attention to before picking them. This includes the size of the library, the degree of activity in terms of maintenance, whether there is any proper documentation, whether the code structure is compatible with your project, and the implementation of accessibility features.