As a junior developer, I would always reach out to a third-party library to cover my needs. Ranging from combo boxes to dialogs and toast messages, if it was out there it was definitely the best choice.
I would later learn that, at times, it’s better to write your own code and be independent. You will understand why after reading this article.
Background: The Project and the Library
The starting point was the need to integrate Matomo into our Angular application to gain more insights regarding its usage.
To do this, there are a couple of libraries that offer wrapper functionality over the Matomo interface, the one that I recommend being ngx-matomo-client.
There was just one requirement we couldn’t cover by the main integration library. We needed to create an event to be used as the trigger in our tag manager configuration.
Matomo offers this by creating a trigger of type Custom Event. And based on their documentation, this is how it should work:
Triggered when a custom event is pushed to the Data-Layer. Allows developers to define manually when this trigger should be triggered by pushing an event to the Data-Layer. This way you can for example execute certain actions when a product is added to the cart, or when a user logs in.
The Decision to Integrate
The Matomo Data Layer is represented by the _mtm object and this is what we needed to interact with to achieve our last requirement. There were close to no examples of people using it and interacting directly with it, so we were not sure if this was the best approach or whether we should continue digging.
Then, we found our holy grail, angular-matomo-tag-manager library.
It was doing just what we needed, a wrapper over sending event information to the Matomo Data Layer. It was working and it was out there. This gave us the assurance we had the right solution, and the library was the obvious choice, right? This was happening three years ago.
Consequences and Confusion
The library depends on Angular v11. At the integration time, our project was using Angular v12, but npm was throwing only warnings for mismatched dependencies, so it didn't catch the attention of the developer who integrated the library.
This became a problem when updating to newer versions of Angular and npm. Both our local and CI/CD builds started failing as npm changed the warnings into errors for mismatching dependencies.
The library had no updates for supporting newer versions of Angular and we were no longer sure why this library was needed, because of course, the person who stumbled upon the issues was not the same as the person who integrated the library, Murphy’s Law at its best.
Pressed for time and unsure of the potential impact of taking the library out, we made the classic mistake of choosing the path of least resistance. We implemented a temporary fix to get our builds running again and moved on, leaving the underlying issue unresolved. Little did we know that the library would no longer get updates and this issue would come back to haunt us repeatedly, each time consuming valuable time and resources.
Newer Angular versions, new version mismatch investigations, the same issues. When we reached this point the third time, we decided to invest a bit more time and finally took the library out.
What is left now, is a one-liner:
window['_mtm'].push({ event: 'eventId' });
Lessons Learned
By far the biggest lesson that I learned from this is that if all you need is a one-liner, don’t integrate a library for it :).
Looking back, the following would have made our journey here easier to navigate:
spend more time understanding what you need before finding a solution (always a lesson, never learned)
have requirement to implementation traceability
don’t hesitate to question legacy code and dependencies
Closing thoughts
As software architects and developers, we often pride ourselves on our ability to leverage existing solutions to solve complex problems efficiently. However, our experience, as described in this article, serves as a reminder that not all integrations are created equal, and the allure of a quick fix can sometimes blind us to the long-term implications of our choices.
Let me know what is your viewpoint when it comes to integrating third-party libraries and if our experience changed your perspective in any way.
Top comments (0)