Lazy Programming: Part 2

Shees Usman
4 min readNov 8, 2020

The right way to be lazy with Angular Directives

This is part2 of my lazy programming series where I will teach programmers to effectively be lazy using my personal experiences and findings. Here is Part 1 if you missed it.

I’ve been dodging work for days now and blaming it on “Learning to delegate.” ever since I’ve moved to a leadership role. Things that I know I can get done in a day I “have to”(read want to) delegate to ensure the people I work with have a wide growth base, also because I iz lazy. So eventually things got pushed back and we ended up in a scenario where an application designed to be run on a small touch screen desktop similar to mobile had button-based scrolls in it, and at every other place there were bugs. The problem was that in all those containers where the scroll buttons had to be added they were added manually with functions being copy-pasted and HTML being copy-pasted as well, the bugs were symptoms of the disease of non-reusability.

Now imagine my annoyance when bugs kept popping up regarding the scrolls every other week and we had to fix them at one place and another and another. So this time when we started a bug sprint to finally clean up these bugs there were around 5 bugs just for the scroll at different places. Now after seeing those the first thing that came to my mind was “They must think I'm crazy if they want me to do that much work fixing it everywhere”. Everyone and I mean everyone in my office should know at this point that I don't like to repeat my code and I ain't gonna fix anything at 5 or 6 places.

However, I used my lazy potato skills to figure out a simpler way to get it all done without me having to refactor a lot of code and it only took me a day of coding just to get it all to work and another day to refactor all the old code to remove the extra stuff and now I have successfully dodged weeks of bug fixes, weeks I will use playing CS:GO 😃.

The thing that we already did right was we were attaching a scroll directive to these containers that needed the scroll. I'm not saying if that directive worked or not…… “ahm, ahm it didn't completely atleast”. But it was still there in the code which worked to my favor. Here is what it looked like before. It's horrific I know. I don't hide it, it was a problem waiting to happen.

So as you can see here the directive had 3 extra variables per usage and 2 extra HTML blocks for the icons, with ViewChilds in the main ts file. And image that they wanted me to copy past all of that and keep all the fixes in sync at around 23 different places.

Now I'm not that active to work that hard and keep working that hard for days on to come with bug fixes. So I ended up rewriting the directive to make it work. I have provided the directive example on my stackblitz and you can see its usage there. I need to keep this blog short and have added plenty of comments to go with the code there. It has some very cool features:
1. It automatically adds the buttons to the container it's attached to.
2. It handles the showing and hiding of the buttons when you reach the top or end.
3. It handles detecting changes in the DOM and automatically checks to see if scrolls buttons even need to be added or not i.e. if the view does overflow it adds the buttons otherwise it doesn't.
4. It can use any componentized button group as its input so you can effectively use any button component with this directive.
5. It's not perfect and is open to future improvements which I plan to do (Yes! that's a feature, perfection is a lie.)

Here is what the directive usage looks like now after refactoring the code to make it do what I want. P.S. It's a structural directive that means it changes the HTML and uses the HTML tag it's attached to as a starting template, which I think is muy bueno!

Stay lazy mi amigos! 👋🏼👋🏼

--

--

Shees Usman

An electrical engineer working in the beautiful world of software for fullstack application development.