Javascript – How to simplifying Type Usage with Abstract Methods in TypeScript

Perhaps this is not the answer you’re looking for but bear with me.

Why do you need inheritance… or classes at all for that matter?

From what I can discern, it appears this is an application to pull weather data from some source and turn it’s response into something usable within the app. Though it could be something that provides weather data… I’m not 100% sure, there’s a lot of context elided.

Whilst it feels quite good to play with the type system and create beautifully expressive types, the question I’d ask at this point is: Are you doing this for your benefit, or someone else’s?

If the answer to that question is the latter, I’d probably aim to make your code simpler. Code gets read far more times than it gets written. If this is purely an exercise to learn inheritance or TypeScript or something else, I’d go with what @jcalz has mentioned above but if this is going to be used, I’d question what the actual need for inheritance is. Perhaps there’s some magic thing I’m not seeing but from what I can see it just adds unnecessary complexity. If something blows up in one class that is inherited by another class, which is inherited by another… you get the point. Debugging can become real difficult real fast.

Ontop of that, newcomers to the codebase will take 1 look at that then decide to go for a 5 minute break first.

That being said, many people write code this way so it’s helpful to at least know. Maybe there is also some hidden benefit to doing it your way… again I have very little context.

The way I’d go about doing this is as follows. Of course, I don’t have the full picture so don’t expect this to make 100% sense in the context of your specific application. Hopefully this gets the general gist, though.

// Request sent
type AppRequest = {
    city: string,
}

// Response received 
type AppResponse = {
    city: number,
    temperature: number,
    $isFresh: boolean,
}

// Data converted to format our app expects
type Converted = {
    city: string,
    temperature: number,
    units: "C" | "F"
}

// Data we know about city before sending the request.. This might be covered in the response 
// but it's impossible to know without seeing the shape of the data
type CityMetaData = {
    canonnicalName: string,
    usesMetricSystem: boolean,
}
let cities: Map<number, CityMetaData> = new Map();
cities.set(1, {
    canonnicalName: "Manchester",
    usesMetricSystem: true
});

// and if you want it to be constant...
cities = Object.freeze(cities);

// This is the function that would replace your need for classes and inheritance entirely
async function runTheThing(_paramsRequired: any): Promise<Converted | null> {
    try {
        const url: AppRequest = await generateURL();
        const response: AppResponse = await groupFetch(url);
        const cityMeta: CityMetaData | undefined = cities.get(response.city);
        if (!cityMeta) {
            throw new Error("handle me properly...")
        }
        return convertToAppData(cityMeta, response);
    } catch(e) {
        // handle errors properly
        return null;
    }
}

async function generateURL(): Promise<AppRequest> {
    // ..
    return {
        city: "Manchester"
    }
}


async function groupFetch(_req: AppRequest): Promise<AppResponse> {
    return {
        city: 1,
        $isFresh: true,
        temperature: 16,
    }
}

function convertToAppData(cityMeta: CityMetaData, res: AppResponse): Converted {
    return {
        city: cityMeta.canonnicalName,
        temperature: res.temperature,
        units: cityMeta.usesMetricSystem ? "C" : "F"
    }
}

One thing to remember about TypeScript is that it’s essentially just a really complicated linter for JavaScript. In JavaScript, we don’t have classes. We have functions masquerading as classes.

The ramifications to taking the object oriented approach are things like:

• Higher memory overhead (and subsequently longer/more frequent GC times, dependent on how the classes are used)
• Readability. "What the heck is type UnWrap<T extends (...args: any) => any>= Awaited<ReturnType<T>> and why do I need this to handle a network response?".
• Code surface area. Would you rather look at 195 different files, one for each country, to dig through and make one implementation change in every file; or would you rather change just 1 function, maybe adding an additional function for the weird requirements of the response from Liechtenstein, specifically.
• Extensibility. If the shape of the data changes, how many places would you have to update in your current code?
• Debugging. If you’re taking the inheritance approach, I can only imagine that you’re inheriting these classes into something else, somewhere down the line. What if an uncaught exception happens way down in the base class. Have you tried reading one of those stack traces… let me tell you, they can be a pain.
• Incoherent transpiled output. TypeScript will do some weird and wonderful things during transpilation, especially if you do things like backfill features for older runtimes. If you’re ever in a situation where you have to comb through the resultant JavaScript (again, not fun), you’d be surprised at just how different the JavaScript can and will be from the inputted TypeScript. This is a non-issue in most cases but it’s always the ones you don’t expect. My general take is to try and keep it as simple as possible and only reach for the top-shelf when the use-case really requires it. Async iterators, Proxies etc.

I’m not trying to rip your code for the sake of ripping your code and I hope that my intentions were clear via written medium. Nice work 🙂