So, if you are already reusing your code across several different projects, why not go the extra mile and convert it into a library that allows you to optimize this code-sharing? Creating a library will allow you to build different versions, keep track of the bugs that you fix and know exactly which version is using each project.
xcframeworks, you won’t find it.
Whether you create your library using the npm structure or other modern standards, it can include any of the common development components, such as an instance, a class, a function, a primitive or an object (even an object containing all of the items listed before).
A JS library can be as complicated as a Singleton object, with its own life cycle and running its tasks in separate threads, or as simple as a file containing a set of handy tools.
In the past, you would create a new file, paste your code and place this file in every project which required it. A common convention was grouping every used library into a project in the vendors folder. This practice was undermined by the fact that dependencies and versioning were difficult to manage. Also, when a library needed to use another library, there wasn’t a clear way to define this relationship. It was even common to find libraries that would copy-paste another full library inside to avoid dependency issues (unfortunately, duplicating a lot of code and hiding these dependencies from other developers).
For this reason, the most common way to create a library nowadays is by using npm. Libraries created for npm must follow an exact convention regarding their structure, so it is clear what the library does and what other dependencies are required.
What If I Don’t Want to Use npm?
However, this adds the problem of versioning. Once you update your library, for example to fix a bug, you will need to manually update the file in every project. Use a local constant or even a comment to set a version number that can identify which version of the library you are using, so you have a quick way to identify which version is using each project.
Using a git repository in GitHub to keep track of the different release versions of your module is always a good idea.
If your library has dependencies with other libraries, remember to clearly document which other libraries, and which versions of them, are needed to use it.
It’s also worth taking into account that your module might need to be loaded in a particular order.
For example, when integrating Bugfender JS manually in a project, it is necessary to use the
For example, before publishing your library with Typescript you will need to compile it. This process outputs the
types of your library. The
types can be understood as
header files and those come in very handy when other developers adopt your code. A Typescript
type is easy to read and understand because it is clearly stated which parameters should receive a function and what values will return.
Web workers come with a few constraints. For example, be careful with DOM manipulation, as it is not possible to directly manipulate the
DOM or access some of the web APIs. But they are an excellent option for intensive network tasks involving sockets or data storage.
An example of web workers in Bugfender
We knew, from our experience with our mobile SDKs, that some users are going to push the SDK to the limits.
To give you an idea of the sheer diversity of developers using Bugfender, at one end of the scale we have game developers sending logs from Unreal Engine, an environment in which keeping a low footprint is mandatory to keep the frame rate as high as possible, and at the other end there are developers using Bugfender to debug the status of real-time sensors, sending hundreds of logs per second.
In the mobile platforms we are proud to say that these tasks are accomplished with an indistinguishable performance impact. That’s thanks to a good data structure (polished over several years) in tandem with good usage of background threads.
We wanted Bugfender JS to be capable of maintaining comparable performance across a wide variety of cases. So we are using Web Workers to do heavy-duty tasks like temporarily storing logs in the
IndexedDB, until they can be sent to the Bugfender server.
Take Into Account the Order in Which Your Library Is Going to Be Loaded
When manually adding the Bugfender SDK to your web app, you need to use the
<script defer src="https://js.bugfender.com/bugfender.js"></script>
That’s because the order in which you load the scripts is not guaranteed. You should take this into account if you create a library by yourself and you want to access it from another script.
This is another reason to use npm. If you do it, everything will be preloaded in a big mountain of code in which everything is accessible and you won’t need to worry about it anymore.
Whether this is a project for yourself, a project that you will share with your company team or an open-source project, first of all you need to document your code!
If you don’t add good documentation to your library, don’t be annoyed when your teammates start sending you private messages in Slack or emails asking how to use it.
Well actually, that’s a best-case scenario… usually they’ll just ignore your library!
Remember, nobody wants to spend their time reverse-engineering your code. Once your library is well-documented you can upload it to GitHub and share it (or even better, follow our tutorial and publish it to npm).
Where to Go From Here?
We at Bugfender are developers ourselves and we love to share our learnings with the community. You can subscribe to our spam-free quarterly newsletter in the box below, or you can continue reading one of these related posts: