While working at REDACTED-2, I reported the following issue.
The frontend files are scattered with contextual functions (declared in another’s closure). It is something totally common in small programs, but in large applications we try to limit its use as much as possible because they do not allow the code to be reused.
Some of the functions that at the time we understood to be reusable, we promoted them to Angular’s filters, thanks to the fact that filters are practically global, and can be called from the JS code. But Angular’s filters exist to be used from within HTML code, essentially to transform text to text.
It is difficult to calculate the amount of reusable code that we currently have embedded in the application. To deal with it, it is best to do it little by little over time, like occasional refactoring, when we find ourselves maintaining the corresponding code.
The idea is to group that reusable code within the utilities file or the utilities directory, organize it according to functionality, make it comply with our standards, deduplicate it, and add enough unit tests.
Group filters into utilities
There are currently more than 150 filters in the application. Each of these filters can be extracted from the file in which it is declared and added to the utilities file, which can then be injected wherever needed, as shown in the example of REDACTED.
Eliminate hacks of yesteryear
Ages ago it was done indiscriminately but now it is considered the result of inexperience: changing the prototype of a language class, such as String, Array, …
For example in REDACTED we define
String.prototype.format = function …. There is already a whole functionality in
utils._.template extensively documented. Also, I recently added
The task is to find the uses of
.prototype in the entire application (about 1200 on January 31, 2019). Some will be about our classes: these are the correct ones. Others will be about JS classes: these are the ones to be patiently moved to utilities. This is really painstaking work.