Barely any tests and several hand-rolled components, some of which were merged only because the author managed to implore somebody to give them an R+ after a few sprints of the branch just sitting there.
A total of 21 people were involved in creating this system and for some insane reason we still had daily standups with almost full attendance.
What's the problem with "hand-rolled components"? Isn't that pretty much the essence of building non-trivial frontend stuff? Or does this have some special meaning in the Angular world?
Not in the case of components which could easily be replaced with a well-tested and proven solution.
Notable among the ones in this project was the date picker - there's a decent number of those available and yet somebody made the decision to hand-roll it.
The result was a mess that for some reason had a 300 LOC service as a part of it. Needless to say minimal tests.
It was a waste of man-days in a project that was already over budget.
There are a lot of date pickers, however if you have a specific UI and UX to implement, it might not be worth trying wrangle one of them into doing what you need it to do.
There's so many integration points (business logic, i18n/l10n, styling, keyboard navigation, accessibility, etc) that I think it's often easier to write your own. Hopefully now that most browsers support <input type="date" />, we can just use that most of the time.
Barely any tests and several hand-rolled components, some of which were merged only because the author managed to implore somebody to give them an R+ after a few sprints of the branch just sitting there.
A total of 21 people were involved in creating this system and for some insane reason we still had daily standups with almost full attendance.