Forem: Bryan Leighton

Getting to Know TypeScript Generics

Bryan Leighton — Mon, 15 May 2023 19:00:00 +0000

Getting to Know TypeScript Generics

Introduction

DRY. Do Not Repeat Yourself. DRY is an acronym that became synonymous with engineering fundamentals. Using DRY, we ensure that we don’t find ourselves with the same lines of code repeated over and over in a repository; indeed when the inevitable need arises to add a single tweak, we come across the predicament of having to go back to each-and-every-single-repeated piece of code to update each individually.

Repeating code was a challenge we quickly came to face during an engagement with a customer where we needed to implement card component selection functionality using React Hooks. The reason we had to repeat ourselves, was that in multiple instances we needed to implement the card selection state to handle multiple data types (string, number, etc.). While in the midst of the ctrl+c, ctrl+p routine, we decided to refactor our components to be more maintainable and properly “reusable” to embrace React’s full capability of custom hooks, while still allowing us to keep our type safety in the realm of TypeScript.

Thus, we had the opportunity to leverage TypeScript Generics as a way to keep DRY, increase maintainability, and keep in the recommended pattern of React Reusable components.

Below, this post will take you through examples of where TypeScript Generics can help DRY up your code, while demonstrating both a generic TypeScript function sample and a React Custom Hook example that follows a closer approach that was used during our customer engagement.

TypeScript Generic Overview

A TypeScript generic is a way of creating reusable components that can work with different types of data rather than one. It allows you to specify a placeholder type that represents the actual type that will be used when the code is executed. For example, you can define an array as Array<T> where T is any type you want.

TLDR Sample

If you prefer to play around with an example, refer to this Code Sandbox React Hook Example

Problem Example

Let’s say that we have two functions that virtually do the same thing, however the parameter may have multiple types. Let’s say that we have a business, and we sell bikes and tennis racquets. Now, both items are different, albeit they both have a price tag attached to them.

So we have a bike type:

type Bike = {
  price: number;
  name: string;
  productType: number; //enum 1 - Electric, 2 - Mechanical
  tires: string;
  weight: number;
  length: number;
  height: number;
}

and a tennis racquet type:

type TennisRacquet = {
  name: string;
  price: number;
  brand: number; // enum 1 - Babolat, 2 - Head, 3- Wilson
  weight: number;
  gripSize: number;
  size: number;
  racquetStrings: []string;
}

Both Bike and TennisRacquet are pretty different in types, however they have a price in common. To find the average cost of our TennisRacquets and Bikes, we have 2 functions:

// Average Bike Cost
const averageBikeCost: number = (bikes: Bike[]) => {
    const sum: number = bikes.map(bike => bike.price).reduce((val, sum) => val + sum, 0);
    const average = sum / bikes.length;
    return average
}

// Average Tennis Racquet Cost
const averageTennisRacquetCost: number = (tennisRacquets: TennisRacquet[]) => {
    const sum: number = tennisRacquets.map(tennisRacquet => tennisRacquet.price).reduce((val, sum) => val + sum, 0);
    const average = sum / tennisRacquets.length;
    return average
}

Both these functions look fairly identical, except for the type. We could combine these two functions, without much difficulty since both just use the price.

const averageProductCost: number = (products: TennisRacquet[] | Bike[]) => {
    const sum: number = products.map(product => product.price).reduce((val, sum) => val + sum, 0);
    const average = sum / products.length;
    return average
}

However, to introduce a bit more complex functionality to get a mapping of the average of each “type” of racquet and bike, E.g. The average cost of all the electric bikes, and the average cost of all Babolat racquets.

If we want to wrap this in one function, countSumMap, we will have to type narrow as shown below.

Now Imagine if we want to extend this by another type if we add to our inventory of products (E.g., type Shoes). We would be increasing this example quite a bit, and it will feel very repetitive

const countSumMap: Map<string, { count: number; sum: number }> = (prods: Tennis[] | Bike[]) => {
    const newMap = new Map<string, { count: number; sum: number }>();
    if ("tires" in prods[0]) {
        prods.map(prod => {
          if (newMap.has(prod.productType)){
              const { count, sum } = newMap.get(prod.productType)
              newMap.set(prod.productType, { count: count + 1, sum: prod.price + sum });
          } else {
              newMap.set(prod.productType, { count: 1, sum: prod.price });
          }
        })
    } else if ("handleSize" in prods[0]) {
        prods.map(prod => {
            if (newMap.has(prod.racquetBrand)) {
                const { count, sum } = newMap.get(prod.racquetBrand)
                newMap.set(prod.racquetBrand, { count: count + 1, sum: prod.price + sum });
            } else {
                newMap.set(prod.racquetBrand, { count: 1, sum: prod.price });
            }
        })
    } else if ("shoeSize" in prods[0]) {
        // ... conditional logic for type Shoe 
    }
    return newMap
}

const tennisRacquetsCountPriceMap = countSumMap(tennisRacquets);
// Map(1) { 'Babolat' => { count: 1, sum: 150 } }
// ... extra logic to find average / mean price
const bikeCountPriceMap = countSumMap(bikes)
// Map(1) { 'Electric' => { count: 2, sum: 1500 } }
// ... extra logic to find average / mean price

This is where Typescript Generics come in handy!

Using Generics

We can use a type Generic <T> to help us reduce this repetitive code.

Notice the code shown below, this is much more concise, and also reusable.countSumMap can be used for any object with a price. keyName is given to allow us to define how we organize our summation and count.

const countSumMap: Map<string, { count: number; sum: number }> = <T>(prods: T[], keyName: string) => {
    if (!keyName) return new Map();

    const newMap = new Map<string, { count: number; sum: number }>();
        prods.map(prod => {
            if (newMap.has(prod[keyName])){
                const { count, sum } = newMap.get(prod[keyName])
                newMap.set(prod[keyName], { count: count + 1, sum: prod.price + sum });
            } else {
                newMap.set(prod[keyName], { count: 1, sum: prod.price });
            }
        })
    return newMap
}
// console.log(countSumMap(bikes, "productType"))
// Map(2) {
// 'Electric' => { count: 2, sum: 1500 },
// 'Mechanical' => { count: 1, sum: 3000 }
// }

countSumMap will infer <T>, as whatever type we pass as our parameter to prods. If our countSumMap takes an argument of Bike[], then it will be able to handle the logic while inferring Bike as the type used in the function body. The same goes with TennisRacquet.

Another Example – React Custom Hook

NOTE: For a Full Working Example, See this Code Sandbox Demo

For this example, assume that we are attempting to set up an item selection that allows us to define a multiSelect mode, so we can either add a single item as our activeItem, or we can select multiple.

Think of holding shift to select multiple.

The first step will be to create a custom hook that will allow us to create a React hook that can receive any type in a Set, and allow items to be stored and modified in that Set. Our custom hook will also receive multiSelect boolean to define if we want to do a single active item, or multi select.

import { useState } from "react";

interface ItemState<T> {
    selectedItems: Set<T>;
}
interface ItemActions<T> {
    handleItemSelect: (item: T, multiSelectMode: boolean) => void;
}
export const useSelect = <T>(items: Set<T>): [ItemState<T>, ItemActions<T>] => {
    const [selectedItems, setSelectedItems] = useState<typeof items>(items);

    const handleItemSelect = (
        item: T,
        multiSelectMode: boolean = false
    ): void => {
        const copiedSet = new Set<T>(selectedItems);
        if (copiedSet.has(item)) {
            copiedSet.delete(item);
        } else {
            if (!multiSelectMode) {
                const newSet = new Set<T>();
                newSet.add(item);
                setSelectedItems(newSet);
                return;
            }
            copiedSet.add(item);
        }
        setSelectedItems(copiedSet);
    };

    return [
        {
            selectedItems,
        },
        {
            handleItemSelect,
        },
    ];
};

To continue the concept of Bikes and TennisRacquets, if we have two distinct lists of items for our Bikes and Racquets, we could use the above code sample to handle selection for both types.

Tennis Racquet Example

import { useSelect } from "../hooks";

function TennisRacquetList({ racquets }: { racquets: ITennisRacquet[] }) {
    const [{ selectedItems }, { handleItemSelect }] = useSelect(
        new Set<string>()
    );
    return (
        <div className="card-wrapper">
            {racquets.map((racquet) => (
                <TennisRacquet
                  key={racquet.GUID}
                  isActive={selectedItems.has(racquet.GUID)}
                  tennisRacquet={racquet}
                  selectOne={handleItemSelect}
                  multiSelect={handleItemSelect}
                />
            ))}
        </div>
    );
}

export default TennisRacquetList;

Bike Example

import { useSelect } from "../hooks";

function Bikes({ bikes }: { bikes: IBike[] }) {
    const [{ selectedItems }, { handleItemSelect }] = useSelect(
        new Set<number>()
    );
    return (
        <div className="card-wrapper">
            {bikes.map((bike) => (
                <Bike
                  key={bike.id}
                  isActive={selectedItems.has(bike.id)}
                  bike={bike}
                  selectOne={handleItemSelect}
                  multiSelect={handleItemSelect}
                />
            ))}
        </div>
    );
}

export default Bikes;

Summary

Generic Typescript types allow reusable functionality for logic that may be very similar but only differ by type. Instead of needing to create type predicates or type narrowing in this use-case, we can instead use TypeScript Generics to achieve reusability, and maintainability in the instance that another type is requesting this same functionality.

References

Acknowledgements

A special thanks to the wonderful team behind this engagement and learning: Bryan, Ivan, Shreyas, Maggie, Bret, Michael, and Maarten.

The post Getting to Know TypeScript Generics appeared first on CSE Developer Blog.

Why I Turned Down My First Ever Full Time Development Job

Bryan Leighton — Sun, 02 Jun 2019 08:04:13 +0000

A fair majority of us have gone through the pains and troughs of at least several months of finding that first dev job, and then heading over to LinkedIn to ecstatically change our job status to flaunt our so well-earned indoctrination and achievement of finally being an industry standard developer.

I had spent over nine months of digging through websites’ careers page and casting my very wide and trusty job-searching net in hopes of landing that one fish, no matter what type it was. I’ve applied to numerous companies that I eventually had forgotten about, only to receive a lovely rejection letter two months later detailing how my resume is very impressive, but just not quite impressive enough or that I’m not the right fit for their team. So then, why after over a hundred applications sent and near as many rejections, did I reject that first holy grail, that first offer to join the prestigious and exclusive club of being a true, professional developer?  

Before answering this question, I’ll give a short telling of my journey as a web developer. I started off in April 2018 with Le Wagon coding bootcamp, where I happened to meet my girlfriend who would convince me (albeit fairly easily) to pick up and move to Berlin in July 2018. I then began hustling as a Teaching Assistant for Le Wagon in Berlin while simultaneously, like rapid-fire, throwing out job applications to any and every company that I could find a job posting that was remotely close to what I was looking for. In November, happened to stumble into contracting and freelancing as a web developer which allowed me luckily to pay the bills enough to make ends-meet.  

Now back to the question at hand, why would I ever even consider turning down the first full time job offer I’ve received as a developer?

The offer wasn’t decent regarding the salary and commute, however it wasn’t terrible either, especially since at this point any offer was like finding a goldmine. When I had negotiated for the salary, I had asked for a salary that is the industry standard for computer science graduates, and I was rebutted since I am only a boot camp graduate. This was fine for me, as I knew not to care about the salary. The commute would be fairly long, but once again, a sacrifice I’d be willing to make to lay my first steps into the realm of professional developer-hood.

So, I decided to try out the company for a day and went in for work to check it out and see what it would be like. We agreed that I’d come on first as a contractor until the manager who’s in charge of the contracts comes back and can process a full time position to join the team. The day went fairly well, and I enjoyed it more than I expected. I had also received a dream position as a React Native developer. I have recently gotten into React as a focus, so this couldn’t have been any better in this regard. With the company being an agency, I also knew that I’d have lots of exposure to several different projects and I wouldn’t be stuck on one API for my entire tenure (hopefully). I even had lots of autonomy and worked the same as every other developer straight off the bat, just completing the tasks handed to me by the project manager.

Everything seems like it had been a beautiful job served to me on a silver platter (not quite gold since the commute was a little longer than I was hoping for). Despite the commute and money, I was prepared to take this job if the offer was worth it. However it wasn’t. Yes… Yes… You read that correctly, I turned down my first ever developer job, and don’t worry I still think I’m fairly nuts for doing it. But, why? Well because of:

1. Mentorship

As a first job and only having around one year of experience, the foremost thing I’m seeking is mentorship. After working the one day with this company, I noticed I was treated the same as all the seasoned developers and there seemed to not be some type of access to a full time mentor that I could pester. The first position you take as a developer should focus on learning and growth. True, I could’ve taken the job and learn lots on my own, but having a senior to whom you can ask questions is something that is valuable. Rather than spending four or five hours sometimes on a feature or piece of code, you can just roll over to them and bug them to help you fix it in a matter of minutes. A company that has mentorship guidelines in place demonstrates that they care about your growth and not only on your output.

2. Self-Worth

After experiencing the first day, I knew that I was being undervalued. I was doing the same work as the other developers, and I was making a fairly smaller amount of money for it. As a first job, I did say earlier that your salary shouldn’t matter as long as you can pay the bills, however coupling a lower salary without mentorship nor educational capital demonstrated to me that they viewed me as a cheap hire. They hadn’t seemed to care to detail any type of investment in my growth or education, and expected me to do the same output as the other developers. If you are to be making much less than the industry standard, I believe you should expect to be compensated with mentorship and tools to help you grow as a developer to make it to the next level. To me, this job didn’t seem to care about such things. 

3. Self-Growth

For this job I’d have an hour and a half commute each way. Although this is ample time for listening to podcasts (which I most certainly did), the tradeoff of such lost time should be worth it. As junior developers, we need to take every opportunity we can get to keep learning and building. So the question we have to ask ourselves is: Does the job dedicate some time in-house for developing personal projects or time learning? If the answer is no, then we should be able to learn and grow on our own time, or it may be better to find a company that provides it, or is willing to be flexible with you to find a mutual solution that benefits your personal growth.

Conclusion

As Junior Developers we must focus on these things as requirements for our first job. I turned down job because ultimately I was viewed primarily as a tool that they had no plans to sharpen. I believe a company hires juniors for two main reasons, 1. We are cheaper hires and 2. They see potential in you and as a possibility to mold you into what they need. I’d much rather work for a company that takes the time to promote my personal growth and coding knowledge. A company that wants to hire me because I’m cheaper, tells me that they aren’t a company that values the individual from their potential, but instead by the profit they can turn. As juniors, we must understand our self-worth and know that we take lower salaries because it should be compensated with options to learn and grow, and of course to have a mentor that we can pester day-in-and-day-out with all of the naïve questions that they once had themselves. One of the greatest things about the developer community is the openness and willingness to give a helping hand when in need. I expect nothing less from a job, because that is the atmosphere I want work in, and a company I’d hope to join.

I'm curious to hear of y'alls experiences with job searching for that first developer job. Getting your foot in the door is extremely important, but how much do you sacrifice and what would be sacrificing too much?

I hope y'all enjoyed!