Recently I needed to do some work on converting strings into
Title Case-format. I had a lot of stuff left to do to implement the feature I was working on and this was just a small part of it. Time was running out so I thought about what to do for five seconds and decided to try and find a package from NPM instead of writing my own function for the conversion. The first package I found had a couple of hundred thousand downloads per week and without further ado I added it to the application. I tested it out in the front-end and voila, it seemed to do the trick.
underscore (at the time none of them unfortunately have a title-case-function). But there’s also concern on being so dependant on frameworks and libraries in an ecosystem that still is changing rapidly. And not to overlook; the dangers of being depedant on code that anyone can upload and share, being discussed in this article.
The use of the
Title Case-package spread throughout the application. It was only later, when implementing a new view in the app that I found out that it had some side-effects on the strings formatted through the function. When implementing this new view, the client wanted the data sorted on a specific field. No problem. But the order of the data being rendered after the sorting had been done seemed way off, not starting alphabetically, which was what the requirements specified. It took some head scratching and looking around in the application to find that it indeed seemed to be the title-case-package that caused this. Inspecting the source-code for the package I found a regexp that did part of the formatting and also removed any special characters. It turned out that the data was being sorted on the unformatted strings and then rendered after the title-case-function had done its work. We ended up writing our own function. (P.S Not implying that implementation in the package is faulty).
The reason for using the package in the first place was that it seemed faster to just use something existing than to write our own function. We’re used to being able to just browse and pick our utilities for stuff like this and a couple of hundred thousand downloads per week should be enough proof that the package does its thing well. Our issue in this case was found by the requirements of the app. But without those it might have taken quite a while to find out that there was an issue with the data being processed, sorted and rendered. The lesson learned in this case is a small one but I think it is valuable when making decisions based on time/cost-effectiveness. How long would it have taken to write a function like this? Probably not that long. After we realised that the package had side effects, it seemed more reasonable to write our own function, which maybe we should’ve done in the first place. So in the future I’m gonna think for a bit longer than five seconds when shamelessly adding utility packages to the apps I’m building. That might prove to be the real time saver.