DEV Community: Abhishek S

CSS Painkillers:has() selector

Abhishek S — Mon, 16 Oct 2023 14:32:34 +0000

This is the first in an ongoing series of posts called CSS Painkillers, covering seldom heard or used CSS concepts easing my development journey. So, if it’s your cup of tea, follow for more!

For the longest time, and especially after the advent of JS frameworks (yes React is a framework too), it has been easier to apply dynamic styles via JS. Dynamic styles are pivotal to modern web applications, since they are the backbone of interactivity. They allow for immediate user feedback after events. Therefore, using application state to conditionally and dynamically apply CSS styles is a common practice which most frameworks facilitate. Let’s take the following example:

There is a table in which the first cell in each row contains a checkbox to select or deselect the row. If the checkbox is checked, you apply a style (let’s say a background color) to the entire row to highlight it. Since using CSS selectors exclusively would be a painful approach, you would use JS. In Vue, you would do something like this:

<tr
    v-for="row in someData"
    :key="row.id"
    :class="{ 'row-selected': row.isSelected } //dynamically adding a class here based on whether row is selected"
  >
    <td>
      <input
        :id="`row-${row.id}`"
        type="checkbox"
        :name="row.data"
        :value="row.isSelected"
        @change="toggleRowSelection"
      />
    </td>
    <!-- Rest of the cells -->
 </tr>

Straightforward and easy to replicate across all frameworks. Until recently, I thought this was only way to accomplish this. I mean who would want to write CSS which looks like this?

/* Original background */
tr {
  background-color: white;
}

/* Change background color when checked, targeting siblings of the input checkbox */
input:checked + td + td + td,
input:checked + td + td,
input:checked + td,
input:checked {
  background-color: yellow;
}

Shivers. Anyway, things changed around 2022 when the eagerly waited has() selector gained major(but not complete) browser support. All Chromium based browsers support it, Firefox is yet to implement it and support on mobile browsers is so-so. For the current state of browser support, check this.

The has() selector, according to MDN, presents a way of selecting a parent element or a previous sibling element with respect to a reference element by taking a relative selector list as an argument. That’s …. surprisingly trivial, but hey, when you haven’t had something for the longest time (still waiting on Subgrid T_T), it’s a breath of fresh air.

Let’s see how the CSS using has() looks like:

tr:has(input:checked) {
  background-color: yellow;
}

And that’s it! A bit anti-climactic if you ask me. But this little guy is deviously powerful.

I just wanted to introduce the topic to you, hence kept the post short with a simple example. But the scope for using the selector is big. Study it well, and the world’s your oyster. And as always, remember it’s a Swiss Army knife, not a golden hammer.

So how do you see yourself using the has() selector? Let me know in the comments!

TypeScript's Discriminated Unions and How I Began to Worry Less

Abhishek S — Fri, 15 Sep 2023 14:25:57 +0000

If you’ve used Typescript in any real capacity, you’ve probably run into unions. Either defined in third party libraries or your own definitions. You can define a union with almost any combination or number of types. They’re pretty simple and generally look like this

type Stage = "empty" | "personalInfo" | "billingInfo";

function allowSubmit(stage: Stage) {
  // Do something
}

This ensures that only computationally supported values are passable.

allowSubmit("empty"); // OK
allowSubmit("inPayment"); // Error: Argument of type '"inPayment"' is not assignable to parameter of type 'Stage'.

This by itself made the code more robust. But what about more advanced cases?

Consider the snippet below. It defines a type for attachments of media posts.

type PostAttachment = {
  type: string; // Can be "image", "video" or "audio"
  url: string;
  altText?: string;
  lowResUrl?: string;
  thumbnailUrl?: string;
  autoplay?: boolean;
};

This looks fine on the surface, but that’s a lot more optional properties than I would like. TypeScript will make you explicitly check for the existence of those properties. That's a lot more if statements. Or if you're lazy, a lot of as string assertions (Officer! He's right here!). In short, it's a pain.

This is where discriminated unions come into play. Let’s break down the conditions for the properties.

When the type is image, you will have altText and lowResUrl
When the type is video, you will have altText, thumbnailUrl and autoplay
When the type is audio, you will have only autoplay

Now, let’s transform the above type to something more intuitive.

type Image = {
  type: 'image';
  url: string;
  altText: string;
  lowResUrl: string;
};

type Video = {
  type: 'video';
  url: string;
  altText: string;
  thumbnailUrl: string;
  autoplay: boolean;
};

type Audio = {
  type: 'audio';
  url: string;
  autoplay: boolean;
};

type PostAttachment = Image | Video | Audio;

That looks a lot cleaner doesn’t it? By anchoring to the type property, TypeScript can narrow down on what fields are available.

function processAttachments(attachment: PostAttachment) {
  if (attachment.type === 'image') {
    // TypeScript knows that 'altText' and 'lowResUrl' exist here
    console.log(attachment.altText, attachment.lowResUrl);
  } else if (attachment.type === 'video') {
    // TypeScript knows that 'altText', 'thumbnailUrl', and 'autoplay' exist here
    console.log(attachment.altText, attachment.thumbnailUrl, attachment.autoplay);
  } else {
    // TypeScript knows that 'autoplay' exists here
    console.log(attachment.autoplay);
    console.log(attachment.lowResUrl); // Error: Property 'lowResUrl' does not exist on type 'Audio'.
  }
}

I've kept the example pretty simple to keep the post short. But that should still give you an idea about how powerful these features are. Discriminated unions offer a robust way to handle different and often complex shapes of data, in a type-safe manner. It’s like a Swiss Army knife—versatile, efficient, and indispensable once you understand its uses. They've made my life easier, and I'm sure they'll do the same for you. But remember it’s a Swiss Army knife, not a golden hammer.

Note: Discriminated unions are a TypeScript feature, not an HR issue!

Software Engineering: The Textbook Omissions

Abhishek S — Wed, 06 Sep 2023 04:29:34 +0000

It’s been two years since I emerged as the victor from interview hell. After countless sleepless nights, hours in code reviews, and thousands of lines of code in production, what are my thoughts on this line of work? Is it everything I dreamt of? Yes and no. I love it, and I’ve learned almost everything I know on the job. But it’s not all sunshine and rainbows. The grass is less green than I thought, and the rose tint on my glasses has worn off. Several gotchas almost got me. So, here are some things I wish I had known earlier in my brief experience as a UI engineer.

It’s not just about being good at the technical stuff

You can churn out 10k lines of code a week, have flawless code reviews, and even know everything there is to know (Hey, Sheldon Cooper). But if you're difficult to work with, that's not going to fly. Being a team player and open to collaboration can take you further than going solo.

Hence, communication is as, if not more, important than code

Facing an approaching deadline or a feature you don’t know how to build? Is there a bug that no matter how much you scratch your brains out, you can’t fix? There’s a high chance that things will work out if you talk about it with your peers/superiors. It's not productive to scour StackOverflow for countless hours all by yourself. People would rather know about issues as soon as possible than get blindsided at the last moment. Bite that bullet and send that Slack dammit.

Communication is also key to efficiency. Good communication helps get ideas across without much hassle. This allows brainstorming to yield more meaningful results. It makes pair programming a fun experience. It makes the workplace a well-oiled machine. Speak out.

Put in a conscious effort towards a work-life balance

It feels so good when you pull in those 30 hours non-stop to get that one feature up and running. It’s immensely gratifying. But before you know it, you’re doing it all the time. And unsurprisingly, you’ve become disconnected. Things you used to like don’t interest you anymore. And you don’t seem to find the time to do them either anyway. And that is a one-way ticket to ‘I hate my job’-ville. You need to make a conscious effort to maintain a work-life balance to ensure both go smoothly. Get yourself some ‘Me’ time. Hang out with your friends and family. Finish that book you’ve left half-read.

So yes, hustle. But hustle responsibly. You don’t want to break down at the age of 25.

Write code for humans, computers can understand it anyway

There are thousands of books and articles on Clean Code practices, that’s how important it is. Code readability takes priority over efficiency. Efficiency cannot come at the cost of spaghetti code. If you can't avoid writing convoluted logic, drop in appropriate code comments. Go a step further to make a document for it.

We created a well-defined coding policy. This helped us put the best practices in place. Peer reviews, peer programming, and maintenance have never been easier. In the end, readability and context matter. Think about the poor chap who has to work on it years down the line (might even end up being you).

And hey, if you work on web UIs like me, who are you kidding thinking about efficiency and performance? I mean come on, it's Javascript.

But you will bury a few bodies

I just told you clean code is important. You watch a ton of YouTube tutorials focusing on how to write the most pristine code. You read a gazillion articles about the correct way of doing things. You now love good engineering, to an extent where it’s intellectual masturbation. But you know what, life ain’t full of unicorns. There are unrealistic deadlines. Realistic expectations. You just need to get shit done. When companies have to choose between well-written software and fast delivery (what is fast delivery? Well this Friday), they often go for speed. Because that’s how businesses work. Sometimes getting something in the hands of customers, even if it's a little shabby, can make or break it. So there is always, however little, technical debt.

So document… everything

Hacked something together for now? Found a cool short way to implement a function off of Stack Overflow? Found a neat niche CSS trick to position that button? Are you using a hardly known edge case library function? Document it. Add good comments. even add a ReadMe with the link to the source. Chances are even you won’t remember it 3 months down the line. And there’s no way another developer jumping into the code would understand it. Have some empathy for future developers (which might include you).

Remember, a comment should ideally not tell me what is going on. That’s the job of well-named variables, functions and files. A comment should tell me the why and in rare cases, the how.

My Key Takeaway: Find your USP and improve on it

If you take just one thing from this article, it should be this. Every person is different. Each of us has something unique to offer. For some, it may be plain right off the bat, but for some, not so much. Take some time off for yourself and think about it ( caution: existential crisis lies ahead! ) What’s something of value that only you can provide? It might be simple. It might be weird.

I come from a creative background (I’m a musician). And I also seem to have great attention to detail. This helps me build pixel-perfect UIs. I always make an effort to think outside the box and further improve on the intended designs. I always look to empower our designers with ways to make our UIs delightful.

My strengths help elevate our products. It helps me provide value on top of my expected responsibilities. So, find your unique strengths. Work towards integrating it into your daily life. You might see an immediate change in all areas of life, not just work.

Something to figure out: It can get overwhelming

Software moves really fast (yeah I’m not talking about you, Enterprise). It can get overwhelming trying to keep up with everything. How do you know which hype is real vs. a dud? How do you know if the 2349239th Javascript released today really is, in fact, a game changer? What if you bet on the wrong stack? What if you misjudged something, and have now suddenly, fallen behind? Let me know in the comments.