DEV Community: Volodymyr Yepishev

The Hidden AI Tax on Tech Debt

Volodymyr Yepishev — Mon, 17 Nov 2025 21:44:28 +0000

TL/DR: the larger your files are, the more you will likely pay for tokens using AI

Sometimes files bloat: someone got lazy and did not separate concerns, someone was rushed to release the feature, someone silently quit or could care less. It is impossible to catalogue all the possible reasons. There are different views on the file sizes in the codebase, especially when it comes to frontend development, with some developers considering fine grained small files with single export, as was the case with one of the Angular's older style guides, or loose suggestions as it was once in React: see what works for you, you can start by putting everything in one file, or something like that. Both are valid approaches and usually developers go by their preferences.

Yet, it is the end of 2025 and everyone and their mother are prompt egineers shipping features daily, while it is often that the velocity of the development is paid for by the quality of the end product and the state of the codebase itself. This often produces bloated files, which is no wonder, but if we are using AI to develop, is the file bloat actually a problem? Certainly it used to be a problem in the old days for the clean code purists, but what of now?

This has lead me to wonder if AI struggles with files as they grow larger. Intuitively it has to, I even asked some AIs if increased file sizes would be more costly to maintain using AI coding agents, the answer I got back was that I was absolutely right (like always when asking AI anything). I needed a way to test it. I found my old repo with a practice project in React, where I had followed one export per file rule and kept everything separated to an extreme: 89 files in total, 1450 lines, with the largest file counting as few as 136 lines. Copying the repo and merging all files into more bulky ones by module I produced a project with the same code, same functionality, but higher code density, down to 17 files, with the largest file sitting with 448 lines. Another copy would take it to the extreme: all the functional code in a single of 1204 lines. I wish I had something larger to test on, but these would have to suffice.

For testing I further generated 80 prompts in 4 different categories: Code Reading & Display, Code Analysis, Information Queries and Code Generation (very primitive, i.e. add comment or add a field to an interface). The methodology for research was rather simple:

open folder with small/large/humongous file(s) with Cursor/Grok;
submit prompts one by one, each in new chat window at regular interval;
~~waste all money on tokens~~ compare token usage/price;
repeat 5 times.

Submitting prompts at regular intervals in that quantity was an impossible endeavor for me, so a Python script was crafted to take care of it and log results with time. A prompt every 2 minutes, 3 repos, 5 runs per each repo to collect the data. It would take a while. Also, every folder would need to be copied from a pristine source into a new path, to prevent the agent from re-using previous knowledge of it.

The initial displayed some interesting results:

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	363,431.00	5,651,776.00	48,670.00	6,063,877.00	0.308
large	641,014.00	4,732,480.00	42,424.00	5,415,918.00	0.338
humongous	817,980.00	4,771,392.00	44,903.00	5,634,275.00	0.424

The repos with smaller files had better cache read numbers and cheaper use as the result. The next run produced similar results, though not identical (probably because the non-deterministic nature of AI, temperature and etc):

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	478,906.00	6,445,127.00	49,960.00	6,973,993.00	0.364
large	700,265.00	4,968,008.00	44,018.00	5,712,291.00	0.372
humongous	1,000,671.00	4,846,604.00	45,552.00	5,892,827.00	0.482

The humongoes file was getting beaten by its smaller counterparts, it was obviously more expensive to maintain, even though it offered exactly same functionality and same code. It was then that I decided the margin could be even more dramatic if the file size increases even more, though I did not have any code to bloat it with, so I merely polluted it with useless comments to ridiculous 3615 lines, which is almost 3 times larger that its original volume.

The results of the next run were absolutely buffling to me: although small and large files were still better than the single humongous, the bloated version which had almost 3 times the volume of the original, did outperform it!

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	337,567.00	5,612,288.00	48,050.00	5,997,905.00	0.312
large	606,161.00	4,459,264.00	40,769.00	5,106,194.00	0.318
humongous	1,024,393.00	5,148,457.00	45,304.00	6,218,154.00	0.448
humongous-bloated	336,670.00	6,513,728.00	53,460.00	6,903,858.00	0.337

I had no reasonable explanation why this happened. My expectation had been the bloated file would tank, yet with cache reads it outperformed every other repo. Without any idea how LLMs treat files in codebases under the hood, I started thinking that after certain size it is somehow split and treated as multiple.

ChatGPT, being LLM, had a different explanation:

The heavily bloated file performed unexpectedly well because most of its added content consisted of repetitive comments, which produced extremely stable and highly cacheable token prefixes—allowing the model to reuse far more of the long-context cache than any of the smaller, more diverse codebases.

I had no expertise to confirm whether it is true or not, so I continued testing. The next run actually revealed the bloated file to be the best:

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	415,485.00	6,425,600.00	49,693.00	6,890,778.00	0.328
large	626,846.00	4,460,160.00	39,830.00	5,126,836.00	0.331
humongous	891,457.00	5,117,184.00	43,634.00	6,052,275.00	0.427
humongous-bloated	348,328.00	6,393,536.00	52,378.00	6,794,242.00	0.320

Inspecting the prompts, code generation was only one of the categories, 20 prompts out of 80, the other three being for reading. It was the time to calculate the average per category based on 5 runs for small + large + humongous and 3 runs form the humongous-bloated.

Here are the results

CODE READING & DISPLAY (PROMPTS 1-20)

The bloated file basically gives same speed as the repo with a bunch of small ones.

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	71,709.40	646,280.20	4,261.00	722,250.60	0.034
large	135,992.80	796,562.80	4,647.00	937,202.60	0.051
humongous	221,114.60	783,213.80	4,396.20	1,008,724.60	0.070
humongous-bloated	55,467.33	769,216.00	4,856.67	829,540.00	0.033

CODE ANALYSIS (PROMPTS 21-40)

Same amazing speed for the bloated monster, on par with larger files on the average.

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	120,173.40	2,113,496.40	16,864.40	2,250,534.20	0.118
large	188,936.40	1,685,606.40	13,997.20	1,888,540.00	0.116
humongous	223,842.20	1,580,842.40	14,566.80	1,819,251.40	0.129
humongous-bloated	121,723.00	2,063,594.67	17,915.67	2,203,233.33	0.116

INFORMATION QUERIES (PROMPTS 41-60)

Here the bloated file takes a dive and small ones prevail.

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	115,328.40	1,907,962.40	13,827.80	2,037,118.60	0.097
large	169,173.80	1,357,708.80	11,282.60	1,538,165.20	0.099
humongous	273,745.80	1,562,889.80	11,829.80	1,848,465.40	0.131
humongous-bloated	103,394.00	2,133,376.00	14,525.00	2,251,295.00	0.107

Code Generation (Prompts 61-80)

Code generation the bigger files lose, though the large files outperform the super small ones.

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	88,252.20	1,365,952.00	14,204.80	1,468,409.00	0.078
large	151,602.60	795,801.60	11,740.40	959,144.60	0.071
humongous	218,112.60	1,050,280.60	14,053.40	1,282,446.60	0.109
humongous-bloated	87,987.67	1,589,269.33	16,841.33	1,694,098.33	0.087

Yet the overal totals still have the repo with smallest files the winner

Repo	Input (w/o Cache Write)	Cache Read	Output Tokens	Total Tokens	Cost
small	395,463.40	6,033,691.00	49,158.00	6,478,312.40	0.327
large	648,632.20	4,643,444.80	41,759.40	5,333,836.40	0.340
humongous	936,815.20	4,977,226.60	44,846.20	5,958,888.00	0.440
humongous-bloated	368,572.00	6,555,456.00	54,138.67	6,978,166.67	0.343

So what is the conclusion here? ~~Bloat your file with comments to make it faster for AI~~ On the average smaller files are more cost effective, as they allow more cache reads when using AI agents, modify less cache. The larger you go, the more expensive it will be for any operation.

As usual, the repo with code.

Automating Addressing Pull Request Comments with AI

Volodymyr Yepishev — Sat, 25 Oct 2025 04:13:12 +0000

Perhaps one of the most common tasks a Frontend Developer gets, is adding a button from time to time. It always sounds ridiculously simple, nothing can go wrong and it is always just a button. We need to add a button that... and days of work follow, integrations come in, migrations, state management. Yet, it is merely a button, how hard can it be to add one?

Ironically this time it was me, who came up with the thought of adding a button. Any time a comment was made on a pull request, I had to copy the file path to open it in IDE to address or look it up. If I only had a button that does it, if I only had one...

So I started thinking: to add a button I would obviously need a browser extension with appropriate permissions to modify the page, yet starting the IDE it would have to be able to communicate with the operating system, which is not something that is possible. However, what an extension can do is perform http requests, which is very convenient and familiar to me, as a frontend developer.

My magic button application would require two components: the server side running on the computer and the browser extension, communicating via REST. The initial idea was to have Send to Cursor button placed near every comment in a pull request, which would trigger the IDE to open specific file. Placing the button on a comment and extracting the file path posed no challenge, but how would the server side know which file path on the operating system corresponds to the file in the pull request? Easy, add a popup to the extension and let user set correlations between repo URL and local repo path, i.e.
https://github.com/Bwca/grind_hackerrank

corresponds to local

C:\Users\vvk\Desktop\projects\grind_hackerrank

Having this relation we can figure out the full path to the file in question and send it to the backend to open inside IDE with the following payload

{
  "filePath": string,
  "comment": string,
  "codeSnippet": string,
  "autoSubmit": boolean
}

Where codeSnippet is the code being commented on and autoSubmit the flag to indicate whether the backend needs to submit the comment to IDE immediately, or merely paste it into the chat window of Cursor.

The flow is the following: the user navigates to a pull request in Azure or GitHub and has new button to resolve in Cursor added to every comment there. They click the button and the comment is transferred from the PR directly to their IDE into the Cursor chat window, where they can either submit it immediately, or modify and submit. The backend would need to handle both cases when there is no instance of IDE running or there are multiple instances running and an appropriate one needs to be chosen. Also, the file should not be opened individually, but in the context of an appropriate git repository.

Although it was tempting to use js/ts for the backend to keep one language, the superior tools available in Python have made me choose Flask over NestJS for my backend. It allowed opening IDE, choosing the correct one if several were open, maximizing it and even simulating user interacting with it (which is something ChatGPT refused to help me with, you are NoFun-GPT).

Some vibe coding magic and voilà, I got myself a spaghetti solution on Windows, that might look like a Frankenstein monster and have filthy architecture, yet it is a working tool that gets the job done.

As a bonus I added a button to streamline Coderabbit suggestions for AI agents, which in addition to pasting the suggestion immediately submits it in Cursor, though I tested it only in Azure.

I called it CursIt ~~because I curse at PR comments~~ short for Cursor it.

As usual the source code.

It is such an amazing experience to engineer something from scratch to solve a problem. Especially when aiming to support different platforms via abstraction.

Perhaps, the true lesson for me here is a browser extension can be turned into a real bridge between a web page and a local application.

Runtime Environment Config in Angular, but Without Dependency Injection

Volodymyr Yepishev — Sat, 08 Jun 2024 22:11:24 +0000

Cover image by Nightcafe, because Gemeni refuses to make images :/

The link to the repo for the code used in the article is provided at the end.

Configuring Angular to use environment variables packed in a json file, which is later pulled and provided by a dedicated service is a topic covered by several articles found on web. Yet, this approach sets a certain restriction on how the environment is provided, so it is no longer a ts import, but rather something provided inside Angular dependency injection system.

In this article we will take a look how to rewire Angular to use a json environment file, but without a separate service to provide it, in fact we are going to explore a way to preserve the environment.ts files for the dev experience. In the end we will be looking at environment.ts, which is transformed into environment.json, so the familiar way of using env files is preserved, at the same time new benefits of having a runtime configuration file is added. Which means migrating to the json file would not trigger any changes in the consuming components, which can be quite convenient if environment is used in many places.

Let us consider we have a typed environment, which has the following model, nesting is for demo purposes, to make it look more complicated:

// src/environments/models/environment.model.ts
export interface Environment {
    api: string;
    something: {
        completely: {
            different: string;
        };
    };
}

And there is a consuming component that merely displays some values:

// src/app/app.component.ts
import { Component } from '@angular/core';

import { environment } from '../environments/environment';

@Component({
    selector: 'app-root',
    standalone: true,
    template: `<p>
        Api: {{ environment.api }}
        <br />
        And now for something completely different:
        {{ environment.something.completely.different }}
    </p>`,
})
export class AppComponent {
    protected readonly environment = environment;
}

Let us add an extra environment environment.development.ts, which is going to be a copy of environment.ts. We will be utilizing it for development, while environment.ts will be to preserve the imports.

This is our starting point, now we need to rewire the application to use environment configuration from a json file instead with minimal changes to src/app and no changes to AppComponent.

The first things that needs to be done is converting the environment typescript file into json. We could leverage npx and ts-node with some edgy inline magic to achieve that. Consider adding the following command to the scripts in package.json (I am using Windows, the amount of backslashes could different on a better OS):

"generate-env": "npx ts-node -O \"{\\\"module\\\":\\\"commonjs\\\"}\" -e \"const fs = require('fs'); const path = require('path'); const { environment } = require(path.join(process.cwd(), './src/environments/', (process.argv[1] || 'environment.development.ts'))); fs.writeFileSync(path.join(process.cwd(), './src/assets/environment.json'), JSON.stringify(environment));\""

Looks like a screenshot from war crimes in programming youtube video, I know. Essentially it is an inlined javascript snippet, here is how it looks formatted:

const fs = require('fs'); 
const path = require('path'); 

const { environment } = require(
    path.join(process.cwd(), 
        './src/environments/', 
        (process.argv[1] || 'environment.development.ts')
    )
);

fs.writeFileSync(
    path.join(
        process.cwd(), 
        './src/assets/environment.json'
    ), 
    JSON.stringify(environment)
);

As you can see, nothing special happens, just a given environment file is converted into json and placed inside /src/assets/environment.json. If no environment file name is passed, default to be used is environment.development.ts.

Updating the start and build commands we get the following:

"start": "npm run generate-env && ng serve",
"build": "npm run generate-env -- environment.production.ts && ng build",

Now the json environment file is going to be generated every time the app is served in development mode or built for production.

Generated file is not yet used by anything, it has to be loaded in the app first. For the purpose of loading and consequently providing it, we will add a special class, EnvironmentLoader, which will have only static methods and properties. Think of it as a static class.

// src/environments/utils/environment-loader.util.ts
import { Environment } from '../models/environment.model';

export class EnvironmentLoader {
    private static env: Environment;

    public static get environment(): Environment {
        return EnvironmentLoader.env;
    }

    public static async loadEnvironment(): Promise<void> {
        const response = await fetch('/assets/environment.json');
        try {
            EnvironmentLoader.env = await response.json();
        } catch (e) {
            console.log('Could not load config, oh no!');
        }
    }
}

It uses fetch, so it is independent of Angular and does not need to depend on HttpClientModule. It has to run before the application is fully bootstrapped, so we have to use the APP_INITIALIZER token and create a provider for it:

// src/environments/providers/provide-environment.provider.ts
import { APP_INITIALIZER, Provider } from '@angular/core';

import { EnvironmentLoader } from '../utils/environment-loader.util';

export const providerEnvironment: () => Provider = () => ({
    provide: APP_INITIALIZER,
    useFactory: () => () => EnvironmentLoader.loadEnvironment(),
    multi: true,
});

With the provider in place, it is time to plug it into the application config:

// src/app/app.config.ts
import { ApplicationConfig } from '@angular/core';

import { providerEnvironment } from '../environments/providers/provide-environment.provider';

export const appConfig: ApplicationConfig = {
    providers: [providerEnvironment()],
};

So far so good. We have the mechanism to create a static json configuration file, we have means to fetch and store it before the application get bootstrapped, now comes the most interesting part: to wire up environment.ts to use the values from the json file without introducing changes to the consumers.

Every time a getter is fired on environment object from environment.ts, it should get its value from the appropriate field of EnvironmentLoader.environment, as those come from the json file. If you are thinking about Proxy, you are on the right path, but plain Proxy would not do as we have an object with several nesting levels. What we need is not just a one Proxy wrapper, but a factory, which could call itself and craft as many proxies on the fly, as we need, every time it encounters an object as a value, when a getter fires.

// src/environments/utils/create-proxy.util.ts
import { EnvironmentLoader } from './environment-loader.util';

export function createProxy<T extends object>(target: T, path = ''): T {
    return new Proxy(target, {
        get: function (obj, prop: string) {
            const fullPath = path ? `${path}.${prop.toString()}` : prop;

            const value = fullPath
                .split('.')
                .reduce((a, c) => a[c], EnvironmentLoader.environment as any);

            if (value && typeof value === 'object') {
                return createProxy(value, fullPath.toString());
            }
            return value;
        },
    });
}

What is happening over there? Every time a getter fires, we calculate the path to the property and reach out to EnvironmentLoader.environment to get the value, if it is an object, we return another Proxy, passing the path along the way, once we reach the primitive value, we return it. This is how we counter paths like environment.something.completely.different.

This is all the heavy-lifting to be done, the only thing left is to update environment.ts and set it to proxy from our factory:

// src/environments/environment.ts
import { Environment } from './models/environment.model';
import { createProxy } from './utils/create-proxy.util';

export const environment: Environment = createProxy({} as Environment);

It is done now, the app is wired to a static configuration json file without any changes to consumers and no extra dependency injection. Just some ts/js magic. Now we can modify configuration after building the app, without having to rebuilt it. Something quite useful when you do not know where you deploy beforehand.

Build once, run anywhere, eh? :)

P.S. the poc repo.

Abstracting State Management in React with Typescript, and its Benefits

Volodymyr Yepishev — Mon, 03 Jun 2024 13:10:36 +0000

Bizarre illustration by Google Gemini AI.

State management is something unavoidable on the UI, be it local component scoped, or global, which in some enterprise applications can grow to gargantuan sizes.

The topic I would like to dwell upon today is tight coupling, which can be created by a state management library, how state management can be abstracted and what benefits and drawbacks it has. Perhaps it should be noted that for the applications that are not maintained in the long run or are short-lived, it does not really matter which state management tool is used or if there is an abstraction at all. Yet, those should be obvious.

As a part of this article we will take a look at Redux in a React application, the coupling it creates, how it can be abstracted and tested and how the state management tool can be swapped once the abstraction has been created, so the public api of the state management remains the same for the app, but the actual provider of it changes.

Firstly let us create a React application and add Redux:

npx create-react-app demo_react-abstracting-state-management --template typescript && install @reduxjs/toolkit react-redux

Following the quick start we can add a counter state, a component to render it, and get something similar to what is found in this commit.

Our counter slice is the following, it is almost identical to the one from the Redux quickstart:

import { createSlice, PayloadAction } from '@reduxjs/toolkit';

import type { RootState } from '../../store';

// Define a type for the slice state
interface CounterState {
    value: number;
}

// Define the initial state using that type
const initialState: CounterState = {
    value: 0,
};

export const counterSlice = createSlice({
    name: 'counter',
    // `createSlice` will infer the state type from the `initialState` argument
    initialState,
    reducers: {
        increment: (state) => {
            state.value += 1;
        },
        decrement: (state) => {
            state.value -= 1;
        },
        // Use the PayloadAction type to declare the contents of `action.payload`
        incrementByAmount: (state, action: PayloadAction<number>) => {
            state.value += action.payload;
        },
    },
});

export const { increment, decrement, incrementByAmount } = counterSlice.actions;

The noticeable difference is that we are placing Redux-related items in store/redux, because we intend to have abstraction in store and store/redux will be one of the implementations. The end goal is to provide an abstract exports from store, in a way that consumers are no longer coupled with a specific state management library.

Apart from a significant amount of boilerplate, which is not critical, what problem does it introduce to the application? The Counter component is now coupled with Redux, and so is our whole application, since it is wrapped in the Redux provider. While this is not a problem if your tech stack is married to Redux, this somewhat is limiting and coupling: changes to Redux in the long run could cause introducing changes to Counter component or other consumers, since all components utilizing imports from Redux will be coupled with it.

See the Counter component:

import { decrement, increment, useAppDispatch, useAppSelector } from '../../store/redux';

export const Counter = () => {
    const count = useAppSelector((state) => state.counter.value);
    const dispatch = useAppDispatch();

    return (
        <div>
            <div>
                <button
                    aria-label="Increment value"
                    onClick={() => dispatch(increment())}
                >
                    Increment
                </button>
                <span>{count}</span>
                <button
                    aria-label="Decrement value"
                    onClick={() => dispatch(decrement())}
                >
                    Decrement
                </button>
            </div>
        </div>
    );
};

Were we to migrate to some other state management tool, the scope of change would be large as well, since Redux would have roots all over the place. You could consider it a soft form of vendor lock, when you could migrate, but the effort is not worth it, it is beneficial for libraries to impose such bounds, but not necessarily beneficial for your application, especially if a better alternative appears on the horizon.

Looking at the exposed state, we can deduct some abstractions: a model for state, a model for hook to access state and methods to modify it and a model for the state provider, which is a wrapper for our application.

Observe the following commit.

So the state and managing methods can be expressed with the following interface:

// src/store/models/counter.state.ts
export interface CounterState {
    count: number;
    increment: () => void;
    decrement: () => void;
}

The hook delivering them would have the following functional interface:

// src/store/models/counter-state-hook.model.ts
import { CounterState } from './counter.state';

export interface CounterStateHook {
    (): CounterState;
}

And, finally, the provider:

// src/store/models/state-provider.model.ts
import { ReactElement, ReactNode } from 'react';

export interface StateProvider {
    (args: { children?: ReactNode }): ReactElement;
}

Evidently, the Redux items, currently present in our application hardly conform to these abstractions, and we would need to create an adapter to make things compliant, so let us create one, which will encapsulate Redux state management:

// src/store/redux/features/counter/counter-hook.ts
import { useCallback } from 'react';

import { useAppDispatch, useAppSelector } from '../../hooks';
import { decrement, increment } from './counter-slice';
import { CounterStateHook } from '../../../models';

export const useCounterHook: CounterStateHook = () => {
    const count = useAppSelector((state) => state.counter.value);

    const dispatch = useAppDispatch();

    const inc = useCallback(() => {
        dispatch(increment());
    }, [dispatch]);

    const dec = useCallback(() => {
        dispatch(decrement());
    }, [dispatch]);

    return {
        count,
        decrement: dec,
        increment: inc,
    };
};

Also, the Redux provider now needs to be adapted to conform to the provider interface:

// src/store/redux/StateProvider.tsx
import { Provider } from 'react-redux';

import { store } from './store';
import { StateProvider } from '../models';

export const StateContextProvider: StateProvider = ({ children }) => {
    return <Provider store={store}>{children}</Provider>;
};

With these in place, we can now provide abstract exports from store which conceal the actual implementation of the underlying state management library.

Here goes our new state management provider:

// src/store/state.provider.ts
import { StateProvider as Provider } from './models';
import { StateContextProvider as ReduxStateContextProvider } from './redux';

export const StateProvider: Provider = ReduxStateContextProvider;

And the hook:

// src/store/counter.hook.ts
import { CounterStateHook } from './models';
import { useCounterHook as ReduxUseCounterHook } from './redux';

export const useCounter: CounterStateHook = ReduxUseCounterHook;

Which in turn means we can use them in Counter:

import { useCounter } from '../../store';

export const Counter = () => {
    const { increment, decrement, count } = useCounter();

    return (
        <div>
            <div>
                <button aria-label="Increment value" onClick={increment}>
                    Increment
                </button>
                <span>{count}</span>
                <button aria-label="Decrement value" onClick={decrement}>
                    Decrement
                </button>
            </div>
        </div>
    );
};

The Counter no longer has any idea which library manages the state, or even if it s a library at all, which is good.

Now, provider for the app, and a small cleanup for imports:

// src/index.tsx
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';

import reportWebVitals from './reportWebVitals';

import { App } from './App';

import { StateProvider } from './store';

const root = createRoot(document.getElementById('root') as HTMLElement);
root.render(
    <StrictMode>
        <StateProvider>
            <App />
        </StateProvider>
    </StrictMode>
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

Some state provider, no details, also good.

Now, before we proceed to migrate to a different state management tool, what we could do is write tests covering the public api of our store module, namely the useCounter hook, which we can do using React Testing Library:

import { act } from 'react';
import { renderHook } from '@testing-library/react';

import { useCounter } from './counter.hook';
import { StateProvider } from './state.provider';

describe('Tests for the counter state', () => {
    test('should increment counter', () => {
        const { result } = renderHook(useCounter, { wrapper: StateProvider });

        act(() => {
            result.current.increment();
        });

        expect(result.current.count).toBe(1);
    });

    test('should decrement counter', () => {
        const { result } = renderHook(useCounter, { wrapper: StateProvider });
        const current = result.current.count;

        act(() => {
            result.current.decrement();
        });

        expect(result.current.count).toBe(current - 1);
    });
});

Once we swap the implementation, the test will show us if everything is working, and we do not need to re-visit consumers.

As a poof of concept for state management tool migration, I chose Zustand, because all the kool kids write articles about it and I had never used it before. Apparently it is pronounced /ˈʦuːʃtant/ and the name itself is taken from German, but don't take my word for it.

npm i zustand

So we create a folder zustand next to the redux, it is going to be another implementation of our abstraction. It has no providers, so we would have to implement and empty one to comply with our abstraction (observe the commit):

// src/store/zustand/StateProvider.tsx
import { StateProvider } from '../models';

export const StateContextProvider: StateProvider = ({ children }) => {
    return <>{children}</>;
};

However, its store creating function actually accepts and interface, and we can pass the existing one we created earlier, CounterState, which means no extra adapters, it will just work (which is amazingly convenient):

// src/store/zustand/counter.hook.ts
import { create } from 'zustand';
import { CounterState } from '../models';

export const useCounter = create<CounterState>((set) => ({
    count: 0,
    increment: () => set((state) => ({ count: state.count + 1 })),
    decrement: () => set((state) => ({ count: state.count - 1 })),
}));

All what is left is to swap implementations for the hook:

// src/store/counter.hook.ts
import { CounterStateHook } from './models';
import { useCounterHook as ReduxUseCounterHook } from './redux';
import { useCounter as ZustandUseCounterHook } from './zustand';

export const useCounter: CounterStateHook = ZustandUseCounterHook; // || ReduxUseCounterHook;

And the state provider:

// src/store/state.provider.ts
import { StateProvider as Provider } from './models';
import { StateContextProvider as ReduxStateContextProvider } from './redux';
import { StateContextProvider as ZustandStateProvider } from './zustand';

export const StateProvider: Provider = ZustandStateProvider; // || ReduxStateContextProvider;

We can run the tests now and make sure switching the underlying library, which does the heavy-lifting for state management had no impact on the store module's public api, which means the consuming components need no changes.

So to sum it up, what are the benefits? Looser coupling for components and state management, more flexibility, easier migration when changing the state management library. What are the drawbacks? Some abstraction overhead and need to write some interfaces to define public api and potentially adapters to make state management library comply.

That's it, have fun, the repo is here :)

Crafting a Global State Hook in React

Volodymyr Yepishev — Sun, 19 May 2024 04:03:37 +0000

As usual, the cover image by AI, this time from Gemini.

The article features typescript generics, run before you can.

Have you ever wanted useState to work across different components, without passing props, using context or throwing a state management tool on top? In this article we will take a look how to craft such state hooks, which would operate in the global scope using rxjs or even a plain javascript object, so no extra libraries are involved.

Let us start with an abstraction to outline what we want. A classical useState application looks something like:

  const [count, setCount] = useState(0);

What can be inferred from this example? We invoke a function that produces an array of a setter and sort-of-a-getter, which we manually have to name. Those also infer the type from the initial value passed to the useState hook.

Since the scope of hook is limited to the invoking component and its children, each invocation requires an initial value, which would not be the case for a hook operating in the global scope, as it would require only one initial value passed to it. That would be the moment the global hook is created, so we would need a function that accepts an initial value and produces a hook, which would return getter/setter pair once invoked, we are talking about a factory here.

Yet, if we are already using a factory, could we do better than returning a getter/setter inside an array? Knowing the state name, we could produce the names ready and pack them inside an object, ready for destructuring, so the end user does not have to type. We would have to type it somehow though, since like all the kool kids, we are using typescript.

Consider the following generic:

type GetterSetterPair<T, S extends string> = {
    [K in [S, `set${Capitalize<S>}`][number]]: K extends `set${Capitalize<S>}` ? (s: T) => void : T;
}

What is going on here? We take a type and a state name, and turn them into an object with getter/setter properties, using Capitalize utility type and some array unpacking to union. So, passed GetterSetterPair<number, count>, we would get { count: number; setCount: (s: number) => void }. Rather convenient, is it not?

This leads us to the following signature for our hook function, since it requires no initial state:

() => GetterSetterPair<T, N>

Where T is the type of the value stored in state and N is the string to generate getter/setter pair. As you might have noticed, this function is not a generic, though it returns one, so where do the types come from? Those would have to be provided by the actual hook factory, which would have the following signature:

type StateHookFactory = <T, N extends string>(stateName: N, initialState: T) => () => GetterSetterPair<T, N>;

Everything is easier when you start with the interface, is it not? So how would a global hook work with rxjs implementation. As you might have guessed, we could create a closure with the factory function and return a simple hook utilizing useState and updating it by subscribing to a subject, namely like this:

import { useCallback, useEffect, useState } from 'react';

import { Subject } from 'rxjs';

import { GetterSetterPair, StateHookFactory } from '../models';

export const subjectStateHookFactory: StateHookFactory = <T, N extends string>(stateName: N, initialState: T) => {
    const subject$ = new Subject<T>();

    return (): GetterSetterPair<T, N> => {
        const [state, set] = useState<T>(initialState);

        useEffect(() => {
            const subscription = subject$.subscribe((s) => set(s));
            return () => {
                subscription.unsubscribe();
            };
        }, []);

        const setState = useCallback((s: T) => {
            subject$.next(s);
        }, []);

        return { [stateName]: state, [`set${stateName.charAt(0).toUpperCase()}${stateName.slice(1)}`]: setState } as GetterSetterPair<T, N>;
    };
};

This way the closure keeps the state inside the subject and no matter how many hooks are invoked, though each of them would have their own useState, they all would still be in sync due to the subscription and updates in the useEffect.

Observing this implementation, one could wonder if something similar can be done with regular tools available in js, without using a library, since we are using a closure and it is a well known way to keep the state. The real question here would be how to telegraph that state to the hooks and how make them listen to it.

It indeed can be done using a Set to keep track of subscribing hooks, and a Proxy to update subscribers to the state changes:

import { useCallback, useEffect, useState } from 'react';

import { GetterSetterPair, StateHookFactory } from '../models';

export const objectStateHookFactory: StateHookFactory = <T, N extends string>(stateName: N, initialState: T) => {
    const listeners: Set<(s: T) => void> = new Set();
    const currentState = new Proxy<{ state?: T }>(
        { state: initialState },
        {
            set(target: typeof currentState, property: string, value: T) {
                target.state = value;
                listeners.forEach((l) => l(value));
                return true;
            },
        },
    ) as { state: T };

    return (): GetterSetterPair<T, N> => {
        const [state, set] = useState<T>(currentState.state as T);

        useEffect(() => {
            listeners.add(set);
            return () => {
                listeners.delete(set);
            };
        }, []);

        const setState = useCallback((s: T) => {
            currentState.state = s;
        }, []);

        return { [stateName]: state, [`set${stateName.charAt(0).toUpperCase()}${stateName.slice(1)}`]: setState } as GetterSetterPair<T, N>;
    };
};

Essentially it is very similar to what happens with the rxjs example, with subscription being replaced by adding and removing setters to the listeners Set.

What is cool about these examples, as both factories implement the same interface, meaning they are interchangeable, i.e. could be assigned to a variable typed with the interface, based on a condition:

import { subjectStateHookFactory } from './subject-state-hook-factory';
import { environment } from '../environment';
import { objectStateHookFactory } from './object-state-hook-factory';
import { StateHookFactory } from './models';

export const stateHookFactory: StateHookFactory =
    environment.REACT_APP_STATE_ENGINE === 'object' ? objectStateHookFactory : subjectStateHookFactory;

I have compiled a repo with a small app generating a random Shakespeare quote using these two hook factories as a proof of concept.

Rather easy, eh?

Reducing the Boilerplate for Services Utilizing Subjects in Angular

Volodymyr Yepishev — Tue, 07 May 2024 04:38:10 +0000

As usually, the cover image was generated by throwing the article header into AI, this time it was nightcafe.

If you are familiar with Angular, chances are, you are most probably familiar with using some type of Subject to hold a state in a service. Perhaps, the most well known example would be Parent and children communicate using a service example from the official documentation. It established rather a pattern, which one can observe navigating through various projects, and the recurring theme is a service that contains a private Subject and exposes a public Observable for subscription.

In this article we will dive into this phenomenon and take a look at how it can be somewhat simplified.

Let us take a close look at the MissionService:

import { Injectable } from '@angular/core';
import { Subject } from 'rxjs';

@Injectable()
export class MissionService {

  // Observable string sources
  private missionAnnouncedSource = new Subject<string>();
  private missionConfirmedSource = new Subject<string>();

  // Observable string streams
  missionAnnounced$ = this.missionAnnouncedSource.asObservable();
  missionConfirmed$ = this.missionConfirmedSource.asObservable();

  // Service message commands
  announceMission(mission: string) {
    this.missionAnnouncedSource.next(mission);
  }

  confirmMission(astronaut: string) {
    this.missionConfirmedSource.next(astronaut);
  }
}

What is the recurring pattern here? Essentially we maintain a private state, using a Subject, and expose a public method to alter the state and a public getter to observe the state. We do not want to expose the Subject itself, so the consumers cannot fiddle with the state and do something outrageous like closing it.

What problem does this approach have? As you might have noticed, for each state we need 2 properties and a method, due to the Observable being a converted Subject, we also have to put a private property before the public one, since otherwise we are referring to a property before its declaration. Also, we have to get creative with naming and come up with 3 variations expressing the same state concept, i.e. for mission announcement we have missionAnnouncedSource, missionAnnounced$ and announceMission, which is juggling 2 words around with a prefix and Finnish notation.

Out there you could also discover similar approaches, but using $$ as prefix for the Subject, so it would be missionAnnounced$ and missionAnnounced$$ or using underscore to differentiate between the private and public properties, i.e. _missionAnnounced$ and missionAnnounced$.

This is a pattern, but can it be simplified in a way, so that a developer does not need to come up with 3 additional fields on a class every time a state is added to a service using a Subject?

I have been thinking about it every time I saw this approach, and I think, I came up with a trick. If essentially what we are doing is setting a state of a Subject and retrieving it as Observable, this could be performed using a getter/setter pair of methods on a function, which would expect state name as a parameter, opposed to creating a setter method per each piece of state. We would simply need a couple of Typescript generics to produce them.

Consider the following generic to provide a list of Subjects on a class:

type SubjectsRecord<T> = {
  [K in keyof T]: T[K] extends Subject<any> ? T[K] : never
}

Once a Subject is extracted, it can be cast into Observable using a different generic:

type ObservableValue<T extends Observable<any>> = T extends Observable<infer A> ? A : never

So far easy, but yet we encounter a problem: Subjects should be public, as generics cannot iterate of private members, this seems to throw a wrench into our idea, as our class would expose the Subjects. However, this does not have to be the case if we make them public, but place inside an object, assigned to a protected property.

Let us name it sources as a tribute to the Source suffix used in the MissionService. With these we are ready to create an abstract stateful service, that will enforce its children to have a pattern where to keep the Subjects and expose two public methods for setting and getting a state by the state name.

import { Observable, Subject } from 'rxjs';

abstract class StatefulSubjectService<T extends Record<string, Subject<any>>> {
  // We pass the interface for sources to get intellisense for the methods
  protected abstract sources: T

  // State name equals one of the property names in sources, which has a Subject
  public getState$<K extends keyof SubjectsRecord<T>>(k: K): Observable<ObservableValue<SubjectsRecord<T>[K]>> {
    return this.sources[k];
  }

  // State name equals one of the property names in sources, which has a Subject, and value type is extracted from its type
  public setState<K extends keyof SubjectsRecord<T>>(k: K, v: ObservableValue<SubjectsRecord<T>[K]>): void {
    this.sources[k].next(v);
  }
}

Note that any extending service would have to communicate the interface for the sources property, so the intellisense for getState$ and setState can work properly, while sources is protected, so it can be used in a generic, but cannot be exposed to some consumer to fiddle with the extending service.

Were the MissionService to extend this abstract service, it would look like this:

@Injectable()
export class MissionService extends StatefulSubjectService<{
  missionAnnounced: Subject<string>,
  missionConfirmed: Subject<string>,
}> {
  protected sources = {
    missionAnnounced: new Subject<string>(),
    missionConfirmed: new Subject<string>(),
  }
}

Adding more states would only result into adding a subject to the interface passed to the underlying StatefulSubjectService and its creation inside the sources field.

The interface passing to the extended service could in theory be reduced to class MissionService extends StatefulSubjectService<MissionService['sources']>, but that constitutes a Typescript violation due recursive self reference, so technically it is a heresy.

Simple as that, a pair of getter/setter and a record of Subjects. No need to juggle words, create affixes or change public/private property order.

Of course, there is a slight api change, so instead of

missionService.announceMission('some mission');

one would use the generic setState method:

missionService.setState('missionAnnounced', 'some mission')

Thence, there is some trade back as you see, and I leave the decision if it is a good idea to you.

My thirst for investigating this topic has been quenched for now :D

Improving Dynamic Component Loader Typings in Angular Using Inputs

Volodymyr Yepishev — Mon, 15 Apr 2024 22:58:39 +0000

Cover image by Google's Gemini, I have no idea why it is a skull.

When I first read about signals in Angular, I was not very amused about two ways of declaring inputs and outputs on the component. However, I figured I would figure out something interesting with those eventually, and I actually did.

So today we will be learning how to improve Dynamic component loader from the official docs with signal bells and whistles.

Yet, first let us define the problem. It shyly hides in ad.service.ts on line 31 and reads as the following:
as {component: Type<any>, inputs: Record<string, unknown>}[]

Why is it a problem? There is no correlation between the actual inputs of the class and the inputs field, and cast to {component: Type<any>, inputs: Record<string, unknown>} is purely cosmetic and serves no purpose. Go on and change one of the inputs to 'banana', typescript compiler has been rendered silent with as.

Understandably, decorated with @Input, a public property string is still a string, and there is no way to write a generic to extract inputs from a typescript class. As you might have guessed, here is where signals enter.

Let us refactor the components to use signals instead of the Input decorator:

import { Component, input } from '@angular/core';

@Component({
  standalone: true,
  template: `
    <div class="job-ad">
      <h4>{{ headline() }}</h4>
      {{ body() }}
    </div>
  `,
})
export class HeroJobAdComponent {
  headline = input.required<string>();
  body = input.required<string>()
}

import { Component, input } from '@angular/core';

@Component({
  standalone: true,
  template: `
    <div class="hero-profile">
      <h3>Featured Hero Profile</h3>
      <h4>{{ name() }}</h4>
      <p>{{ bio() }}</p>
      <strong>Hire this hero today!</strong>
    </div>
  `,
})
export class HeroProfileComponent {
  name = input.required<string>();
  bio = input.required<string>();
}

In terms of functionality nothing has changed, the ads are produced as they were before, yet, these properties receiving strings have changed their types to InputSignal<string>, which means we could write a generic that accepts a class and extracts them, unpacking the underlying input type like this:

type ComponentInputs<T> = {
  [P in keyof T]: T[P] extends InputSignal<infer A> ? A : never;
};

Neat? Now let us create a factory function that produces ads inside the AdService class, utilizing our new generic, which extracts inputs from a component class:

private produceAd<T>(component: Type<T>, inputs: ComponentInputs<T>): { component: Type<T>; inputs: ComponentInputs<T> } {
    return {
      component,
      inputs,
    };
}

Essentially this is it, we can remove the embarrassing as cast and populate the ad array using our factory function, which allows us to have type safety even for this dynamic adventure:

import { Injectable, Type, InputSignal } from '@angular/core';

import { HeroProfileComponent } from './hero-profile.component';
import { HeroJobAdComponent } from './hero-job-ad.component';

type ComponentInputs<T> = {
  [P in keyof T]: T[P] extends InputSignal<infer A> ? A : never;
};

@Injectable({ providedIn: 'root' })
export class AdService {
  getAds() {
    return [
      this.produceAd(HeroProfileComponent, {
        name: 'Dr. IQ',
        bio: 'Smart as they come',
      }),

      this.produceAd(HeroProfileComponent, {
        name: 'Bombasto',
        bio: 'Brave as they come',
      }),

      this.produceAd(HeroJobAdComponent, {
        headline: 'Hiring for several positions',
        body: 'Submit your resume today!',
      }),

      this.produceAd(HeroJobAdComponent, {
        headline: 'Openings in all departments',
        body: 'Apply today',
      }),
    ];
  }

  private produceAd<T>(
    component: Type<T>,
    inputs: ComponentInputs<T>
  ): { component: Type<T>; inputs: ComponentInputs<T> } {
    return {
      component,
      inputs,
    };
  }
}

Try messing with inputs and observe typescript compilation error, instead of a runtime error about missing imports when used with as cast and @Input decorators.

Pretty cool, eh? See the full code on stackblitz.

Annoying Cat Extension

Volodymyr Yepishev — Fri, 29 Mar 2024 21:27:15 +0000

The link to the full code for this article is at the end of this article.

Once upon a time I was involved in adding an Easter egg to an application that once a year, on April 1, would cause a famous doge meme to slide out from the left side of the screen. When hovered over, the doge would hide, to come back after some time. It was hidden from serious people in production by a boolean flag, but the development team loved it.

So recently I thought why not create a bookmarklet or extension to get similar experience anywhere, any time? In the end I decided to go with browser extension, since packing an image as base64 into a bookmarklet makes it too big to be used as a bookmarklet and would only work when pasted into browser's console, I also decided I would want to make it more flexible this time, with the image sliding from random side of the screen, left, right, top or bottom.

Now, I do not have a doge meme dog to take a picture of, but I still have a picture of my cat peeping out of a box, which looks perfect for this type of thing, though the approach I intend to use during the implementation will not rely on the image dimensions, so any picture would do really.

Being a developer, removing the background on the image was the hardest part, but I digress.

First we create a folder for the extension and add the assets folder and the image to it, i.e. in assets/annoying-cat.png. Having a folder is not necessary, but it keeps things neat and tidy. Also, storing the image as a file compared to base64 string in the javascript file is also less messy when it comes to reading the code.

The next step is to add manifest.json, which should have web_accessible_resources section to allow using the image from assets:

{
  "manifest_version": 3,
  "name": "Annoying Cat",
  "version": "1.0",
  "description": "Annoys you.",
  "permissions": [
    "activeTab"
  ],
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"]
    }
  ],
  "web_accessible_resources": [
    {
      "resources": ["assets/annoying-cat.png"],
      "matches": ["<all_urls>"]
    }
  ]
}

I don't create browser extensions too often, so I had to look it up, as I originally went with relative image path and failed miserably.

Now for content.js, I decided not to just pile all the code there, but put it inside an IIFE in case I ever want to extract it for a bookmarklet or to paste it into console. As a tribute to ~~real~~ other programming languages, I decided to call it main:

(function main() {
    /** here be annoying cat */
})()

First of all, let us add some basic stuff, like enumeration to determine direction from which the image is going to appear as well as the css classes we use to manipulate it:

const DIRECTIONS = {
    TOP: 3,
    RIGHT: 1,
    BOTTOM: 2,
    LEFT: 4,
};

const CSS_CLASSES = {
    IMAGE: 'annoying-cat-image',
    SHOW: 'annoying-cat-image-show',
    HIDE: 'annoying-cat-image-hide',
};

To utilize those classes, we need to create them and attach to the document's head. Let's make the image positioned fixed, with ridiculous z-index and outside the viewport initially, with some transitions for sliding out and hiding (this will happen when the image receives mouse over event).

function addStyles() {
    const style = document.createElement('style');
    style.innerHTML = `
    .${CSS_CLASSES.IMAGE} {
        position: fixed;
        left: -100vw;
        top: -100vh;
        z-index: ${Number.MAX_SAFE_INTEGER}
    }

    .${CSS_CLASSES.HIDE} {
        transition-property: top, bottom, left, right;
        transition-duration: 0.2s;
        transition-timing-function: ease-out;
    }

    .${CSS_CLASSES.SHOW} {
        transition-property: top, bottom, left, right;
        transition-duration: 1s;
        transition-timing-function: ease-out;
    }`;

    document.head.appendChild(style);
}

Creating the image itself and adding source to it can be done using a couple of functions, I like to separate setting the source, because it might be URL or base64, which makes it easier to change if it is a separate function:

function createImage() {
    const el = document.createElement('img');
    el.src = getImageSource();
    el.classList.add(CSS_CLASSES.IMAGE);
    document.body.appendChild(el);
    return el;
}

function getImageSource() {
    return chrome.runtime.getURL('assets/annoying-cat.png');
}

As we do not want to have the image sliding out from the same spots, we need a function to get random numbers, so we can get the random side, and the left offset if it is top/bottom or top offset if it is left/right. This means our function would have to be able to generate a random number between two given values:

function getRandomNumber(max, min = 1) {
    const minCeiled = Math.ceil(min);
    const maxFloored = Math.floor(max);
    return Math.floor(Math.random() * (maxFloored - minCeiled + 1) + minCeiled);
}

Having this function we can create a function that generates a random direction, since our directions are a range from 1-4, we need a random number in that range:

function getDirection() {
    return getRandomNumber(4);
}

Now, for an interesting part: since we do not want to rely on hard-coding width/height of the image, but calculating them on the fly, we cannot completely hide it, or those values would be 0, we would have to set the image's visibility to hidden instead. Moreover, since the image is going to appear from a random side and position, it means we would have to reposition it before changing its visibility to visible and allowing its appearance via css classes with transitions. This means the invisible image will be flying through the screen at some point.

In order to avoid awkward situation with flying image becoming visible before we want it to, let us delegate this event to a function, which would add the show class to the image, adjust its visibility and perform a callback to set its other properties, which will vary, depending on the side of the screen, from which the image appears:

function show(slideCb) {
    setTimeout(() => {
        img.classList.add(CSS_CLASSES.SHOW);
        img.style.visibility = 'visible';
        slideCb();
    }, 1000);
}

To handle all 4 cases for each screen side, we can add 4 function to handle each case (could probably be reduced to 1), they are rather similar in structure, they reposition the image and set properties for it to slide out ~~annoyingly~~.

The pattern is the following: we position the image behind the side, from which it is supposed to emerge, rotating it accordingly, get random position for its left or top offset and showing it with a delay. Note the usage of window.getComputedStyle to dynamically obtain its width and height.

function slideFromTop(img) {
    img.style.visibility = 'hidden';
    img.style.transformOrigin = 'unset';
    img.style.top = -1 * window.getComputedStyle(img).height.replace('px', '') + 'px';
    img.style.left = getRandomNumber(window.innerWidth - window.getComputedStyle(img).width.replace('px', '')) + 'px';
    img.style.transform = 'scaleY(-1)';
    show(() => {
        img.style.top = '0';
    });
}

function slideFromBottom(img) {
    img.style.visibility = 'hidden';
    img.style.transformOrigin = 'unset';
    img.style.top = 'unset';
    img.style.left = getRandomNumber(window.innerWidth - window.getComputedStyle(img).width.replace('px', '')) + 'px';
    img.style.transform = 'scaleY(1)';
    img.style.bottom = -1 * window.getComputedStyle(img).height.replace('px', '') + 'px';
    show(() => {
        img.style.bottom = '0';
    });
}

function slideFromLeft(img) {
    img.style.visibility = 'hidden';
    img.style.transformOrigin = 'left top';
    img.style.top = getRandomNumber(window.innerHeight - window.getComputedStyle(img).width.replace('px', '')) + 'px';
    img.style.transform = 'rotate(90deg)';
    img.style.left = -1 * window.getComputedStyle(img).height.replace('px', '') + 'px';
    show(() => {
        img.style.left = window.getComputedStyle(img).height;
    });
}

function slideFromRight(img) {
    img.style.visibility = 'hidden';
    img.style.transformOrigin = 'right top';
    img.style.top = getRandomNumber(window.innerHeight - window.getComputedStyle(img).width.replace('px', '')) + 'px';
    img.style.left = 'unset';
    img.style.transform = 'rotate(-90deg)';
    img.style.right = -1 * window.getComputedStyle(img).height.replace('px', '') + 'px';
    show(() => {
        img.style.right = window.getComputedStyle(img).height;
    });
}

With these handlers ready, it is time to write a function that would call the appropriate handler, for the given direction:

function slideOut(img, dir) {
    img.classList.remove(CSS_CLASSES.HIDE);
    img.classList.add(CSS_CLASSES.SHOW);
    if (dir === DIRECTIONS.TOP) {
        slideFromTop(img);
    } else if (dir === DIRECTIONS.BOTTOM) {
        slideFromBottom(img);
    } else if (dir === DIRECTIONS.LEFT) {
        slideFromLeft(img);
    } else if (dir === DIRECTIONS.RIGHT) {
        slideFromRight(img);
    }
}

Showing image is only a part of our intention, we also need a function to reset it back to hiding, with a fast transition:

function reset(img, dir) {
    img.classList.remove(CSS_CLASSES.SHOW);
    img.classList.add(CSS_CLASSES.HIDE);
    const offset =
      -1 * window.getComputedStyle(img).height.replace("px", "") + "px";
    if (dir === DIRECTIONS.TOP) {
      img.style.top = offset;
    } else if (dir === DIRECTIONS.BOTTOM) {
      img.style.bottom = offset;
    } else if (dir === DIRECTIONS.LEFT) {
      img.style.left = offset;
    } else if (dir === DIRECTIONS.RIGHT) {
      img.style.right = offset;
    }
}

The function to make image slide out from random direction can be crafted using a factory, which accepts the image itself and a cooldown timer:

function createSlideOutFunction(img, showUpCoolDown) {
    let slideDirection;

    return () => {
        reset(img, slideDirection);
        setTimeout(() => {
            slideDirection = getDirection();
            slideOut(img, slideDirection);
        }, showUpCoolDown);
    };
}

With all needed functions in place, all that is left is to evoke them in a proper sequence:

  addStyles();

  const img = createImage();
  // annoy every 2 seconds
  const showUpCoolDown = 2 * 1000;
  const slideOutRandomly = createSlideOutFunction(img, showUpCoolDown);
  img.addEventListener("mouseenter", slideOutRandomly);
  slideOutRandomly();

Now the unpacked extension can be loaded in chrome :)

The source code is available on github.

How to Create Bookmarklets Using Libraries Like React

Volodymyr Yepishev — Thu, 14 Mar 2024 01:12:38 +0000

This article was generated by a human :)
The cover image provided by Gemini AI. UNLEASH BOOKKALLETT POWER!

The full code for this article's bookmarklet is available in the end.

Long time ago, in a galaxy far away, when web developers did not use node_modules to create web pages. Today we will discover how these forgotten techniques of using plain script tags and some js to create rich bookmarklets.

Yet, let us start with the basic, what is a bookmarklet? Essentially it is a bookmark, but with some javascript in place of the URL, in a format, which can be pasted in the browser's address bar and get executed, for example, try pasting the following code into the address bar and press enter:

javascript:alert('hello!');

Rather primitive, eh? However, this ability to execute javascript on the fly opens a huge field of possibilities. Do not feel like typing branch names manually when creating one on the work item? Have a bookmarklet to generate them. Want to check what does google analytics send? Have a bookmarklet to log its data in real time. Imagination is the limit.

Let us imagine a scenario, where we decided to code a bookmarklet with some fancy interface, so it creates a separate element and displays some data. To make it more interesting, let us use a css framework for the looks and a js library for components. For this demo, the bookmarklet will render a simple counter with a button that increments the displayed click count.

Resources we will be using:

Bulma for css (simply because it does not use js);
React for components;
ReactDOM to render our React components.

All of these need to be loaded prior to any serious work, so let's create some functions to load them and await until we are ready to proceed. We can use CDNs to load everything we need. Note, that for this proof of concept we will not encapsulate our bookmarklet into an iframe, we will use a regular div to host our micro bookmarklet application instead.

javascript: (async () => {
    await loadResources();

    /** Here our main logic will reside */

    async function loadResources() {
        return Promise.all(
            [
                'https://unpkg.com/react@18.1.0/umd/react.production.min.js',
                'https://unpkg.com/react-dom@18.2.0/umd/react-dom.production.min.js',
            ]
                .map(loadScript)
                .concat(['https://cdn.jsdelivr.net/npm/bulma@0.9.4/css/bulma.min.css'].map(loadStyleSheet)),
        );
    }

    async function loadScript(src) {
        return new Promise((res) => {
            const script = document.createElement('script');
            script.src = src;
            script.onload = res;
            document.body.appendChild(script);
        });
    }

    async function loadStyleSheet(src) {
        return new Promise((res) => {
            const link = document.createElement('link');
            link.rel = 'stylesheet';
            link.href = src;
            link.onload = res;
            document.head.appendChild(link);
        });
    }
})();

Take a note, how loading of scripts and stylesheets is combined into a single Promise, which allows us to postpone the execution until everything has been fetched from the web.

Once all the resources have been obtained, it is time to create an anchor component

...
    const root = document.createElement('div');
    document.body.appendChild(root);
...

What is interesting, is that once the scripts have loaded, React becomes immediately available with all its features, and you can create functional components, use hooks and do whatever you like with it. And though, there is no fancy jsx available immediately, it still could be used if babel is loaded directly into the bookmarklet, but that would be too much for this demonstration.

For now let us add some basic React components to make up a counter

...
    function Counter() {
        const state = React.useState(0);
        const count = state[0];
        const setCount = state[1];
        const updateCount = () => {
            setCount((count) => count + 1);
        };
        return React.createElement(
            'div',
            { className: 'counter' },
            React.createElement(CounterText, { count: count }),
            React.createElement(ButtonCounter, { clickHandler: updateCount }),
        );
    }

    function CounterText(props) {
        return React.createElement('div', null, `You clicked ${props.count} times!`);
    }

    function ButtonCounter(props) {
        return React.createElement('button', { className: 'button is-primary', onClick: props.clickHandler }, `Click Me!`);
    }
...

There we have it, a counter with 2 child elements, the only thing remaining now is to create a container with fixed positioning (just so it sticks) for it and render it using ReactDOM. Though components have already been created using React, ReactDOM is needed to get them rendered on a web page.

...
    const reactHost = React.createElement(
    'div',
    {
        style: {
            position: 'fixed',
            top: '400px',
            left: '600px',
            backgroundColor: 'antiquewhite',
            padding: '100px',
        },
    },
    React.createElement(Counter),
);
ReactDOM.render(reactHost, root);
...

Putting it all together, we get a ridiculously over-engineered bookmarklet, that acts like a mini-application on its own.

javascript: (async () => {
    await loadResources();

    const root = document.createElement('div');
    document.body.appendChild(root);

    const reactHost = React.createElement(
        'div',
        {
            style: {
                position: 'fixed',
                top: '400px',
                left: '600px',
                backgroundColor: 'antiquewhite',
                padding: '100px',
            },
        },
        React.createElement(Counter),
    );
    ReactDOM.render(reactHost, root);

    function Counter() {
        const state = React.useState(0);
        const count = state[0];
        const setCount = state[1];
        const updateCount = () => {
            setCount((count) => count + 1);
        };
        return React.createElement(
            'div',
            { className: 'counter' },
            React.createElement(CounterText, { count: count }),
            React.createElement(ButtonCounter, { clickHandler: updateCount }),
        );
    }

    function CounterText(props) {
        return React.createElement('div', null, `You clicked ${props.count} times!`);
    }

    function ButtonCounter(props) {
        return React.createElement('button', { className: 'button is-primary', onClick: props.clickHandler }, `Click Me!`);
    }

    async function loadResources() {
        return Promise.all(
            [
                'https://unpkg.com/react@18.1.0/umd/react.production.min.js',
                'https://unpkg.com/react-dom@18.2.0/umd/react-dom.production.min.js',
            ]
                .map(loadScript)
                .concat(['https://cdn.jsdelivr.net/npm/bulma@0.9.4/css/bulma.min.css'].map(loadStyleSheet)),
        );
    }

    async function loadScript(src) {
        return new Promise((res) => {
            const script = document.createElement('script');
            script.src = src;
            script.onload = res;
            document.body.appendChild(script);
        });
    }

    async function loadStyleSheet(src) {
        return new Promise((res) => {
            const link = document.createElement('link');
            link.rel = 'stylesheet';
            link.href = src;
            link.onload = res;
            document.head.appendChild(link);
        });
    }
})();

Though this demonstration may look rather primitive and awkward, as it lacks encapsulation for styles and downloaded javascript libraries, the approach can be used to make some amazing bookmarklets, which look like fully fledged widgets, check out this demo of a bookmarklet I made to view Google Analytics data being collected on a web page, and even pause it, which uses React, UI-Kit and iframe to isolate the bookmarklet app from the main page.

The demo for ga bookmarklet I made

Hope you learned something new :)

Typing Object Keys With Enum Values Using Typescript

Volodymyr Yepishev — Wed, 01 Nov 2023 03:49:23 +0000

Cover image generated by throwing headline into nightcafe AI, as usual.

Enums provide an excellent way to group constants in Typescript, but how to type objects when there is a need to use them to generate object keys? Today we will explore this.

We will discover how to perform dynamic typing for objects which utilize enum values as keys to point to a given value type. This can prove beneficial in a situation where one has an enum of features and wants to turn it into a dictionary to denote which features are enabled, and which are not, or if an enum of grades needs to be turned into a dictionary to show statistics how many of each grade students scored during a test.

Crafting the functional interface

Foremost, it should be mentioned that there are two ways to create enumerations in Typescript, the first one being using enum keyword and the other one using a constant with as const. The latter has been discussed in this article. The approach we are going to study is applicable to both. To make matters more interesting, let us assume the object manufactured from the enum might have only several of its values, not the whole set.

Therefore, we want to be able to pass an array of enum values and some other arguments to a function, provide a value type for the new mapped object's keys and have the returned type based off this data.

This can be expressed via the following functional interface (fear not, detailed explanation under the code block):

interface  Converter<A  extends  Array<unknown>, V> {
    <T>(keys: Array<T>, ...args: A): Record<string & T, V>
}

The generics here represent the following:

A an array of additional values, passed to the converted function, left as an array of unknown, since the interface does not really care about them;
V the type for the values, the mapped object keys will be pointing, this will provide the flexibility, we do not impose any restrictions;
T this is the enum type, which will be passed.

Simple as that, this is all the heavy lifting that needs to be done, what is left now is to implement the interface for a couple of use cases.

Case 1: Grading students

Consider the following situation: students have written a test and we want to collect data, how many occurrences of each grade there is in the test.

We will be using both types of enumerations for demo purposes:

enum  Grades {
    a = 'A',
    b = 'B',
    c = 'C',
    d = 'D',
    e = 'E',
    f = 'F'
}

const  GRADES = {
    a: 'A',
    b: 'B',
    c: 'C',
    d: 'D',
    e: 'E',
    f: 'F'
} as  const;

The imaginary graded students come from an api and correspond to the following interface:

interface  GradedStudent {
    name: string;
    grade: string;
}

Hence, let us implement grade checker function, we know that one of the extra arguments is going to be the array of graded students and we will be mapping to an integer, since we are counting grades:

const gradeChecker: Converter<[Array<GradedStudent>], number> = (keys, students) => {
    const gradesStats: Record<string, number> = {};
    const keySet = new  Set(keys as  string[]);

    students.forEach(s => {
        const grade = s['grade'];
        if (keySet.has(grade as  string)) {
        gradesStats[grade] = (gradesStats[s['grade']] ?? 0) + 1;
        }
    });

    return gradesStats;
}

As some test data, let us also to generate an array of graded students

const studentGrades: Array<GradedStudent> = Array.from({ length: 20 }, (_, index) => ({
    name: `Student ${index + 1}`,
    grade: (String.fromCharCode(65 + (index % 6)) as  unknown  as  typeof  GRADES)
}) as  unknown  as  GradedStudent);

As such, we can now turn an array of enum values into a dictionary of grade-count by passing an array of them into our gradeChecker function along with the mocked graded students:

// for 'as const', resulting type 'Record<"A" | "B" | "C" | "D" | "E" | "F", number>'
const grades = gradeChecker(Object.values(GRADES), studentGrades);
console.log(grades);
// { "A": 4, "B": 4, "C": 3, "D": 3, "E": 3, "F": 3 }

// for 'enum', resulting type 'Record<Grades, number>'
const grades2 = gradeChecker(Object.values(Grades), studentGrades);
console.log(grades2);
// { "A": 4, "B": 4, "C": 3, "D": 3, "E": 3, "F": 3 }

What really makes this approach interesting, is that the resulting object type is based on the input, so it is dynamic, were we to pass only a single grade type, we would have gotten a different result, i.e. if we tried counting only C grades:

// for 'as const', resulting type 'Record<"C", number>'
const cGrades = gradeChecker([GRADES.c], studentGrades);
console.log(cGrades);
// { "C": 3 }

// for 'enum', resulting type 'Record<Grades.c, number>'
const cGrades2 = gradeChecker<typeof  Grades.c>([Grades.c], studentGrades);
console.log(cGrades2);
// { "C": 3 }

Take note, how as const shines here, providing better typing experience compared to enum, which requires explicit passing of typeof Grades.c to achieve same result.

Case 2: Determining Feature Status

For this scenario, let us imagine that our application has a number of features, the name of which are stored in an enum, but requires an API call to fetch a configuration object, to determine which of them are enabled, and which not. Now we want to turn the list of features into a dictionary, where key is feature name and value is its enabled or disabled state, represented by a boolean.

We will use the following hypothetical feature enumerations (both enum and as const for demo purposes):

enum  Features {
    SearchByName = 'searchByName',
    SearchBySurname = 'searchBySurname',
    SearchById = 'searchById',
}

const  FEATURES = {
    SearchByName: 'searchByName',
    SearchBySurname: 'searchBySurname',
    SearchById: 'searchById',
} as  const;

With the following feature status interface and a config object:

interface  FeatureStatus {
    name: string;
    status: 'on' | 'off';
}

const  CONFIG: FeatureStatus[] = [
    {
        name: 'searchByName',
        status: 'on'
    },
    {
        name: 'searchBySurname',
        status: 'off'
    },
    {
        name: 'searchById',
        status: 'on'
    }
];

Implementing feature checker is going to be easier here, since we do not have any extra arguments to pass, we are assuming the config object is already available inside the checker function:

const featureChecker: Converter<[], boolean> = (featureNames) => {
    const featuresStatus: Record<string, boolean> = {};
    const featuresSet = new  Map(CONFIG.map(f => ([f.name, f.status])));

    featureNames.forEach(name => {
        featuresStatus[name as  string] = featuresSet.get(name as  string) === 'on';
    });

    return featuresStatus;
}

Thus checking feature availability is as easy as passing the list of features to be checked:

// for 'as const', resulting type 'Record<"searchByName" | "searchBySurname", boolean>'
const featuresAvailable = featureChecker([FEATURES.SearchBySurname, FEATURES.SearchByName]);
console.log(featuresAvailable);
// { "searchBySurname": false, "searchByName": true }

// for 'enum', resulting type 'Record<Features.SearchByName | Features.SearchBySurname, boolean>'
const featuresAvailable2 = featureChecker<Features.SearchBySurname | Features.SearchByName>([Features.SearchBySurname, Features.SearchByName]);
console.log(featuresAvailable2);
// { "searchBySurname": false, "searchByName": true }

Once again, note how neater as const is.

That concludes it, how you learned something. I know I did :)

P.S. the code is available in the playground.

Deep Readonly Generic in Typescript

Volodymyr Yepishev — Sat, 16 Sep 2023 03:07:08 +0000

The image is how NightCafe sees deep readonly type.
The link to the playground for this article is down below.

Immutability could be useful for certain cases when building applications, and today we will take a look how to enforce immutability using Typescript.

Normally to get an immutable object, it would need to be frozen with the appropriate JavaScript function, but that would only freeze a single nesting level of it and would not affect anything nested inside, whether in its objects inside properties or arrays of objects.

A possible solution would be to iterate over all properties recursively, freezing all objects and repeating the process for any nested arrays of objects.

However, Typescript provides means that can potentially eliminate this need if used wisely.

Suppose we have the following interfaces representing a family:

interface Person {
  firstName: string;
  lastName: string;
  age: number;
  children?: Person[];
}

interface Family {
  parents: Person[];
  grandparents?: {
    paternal: Person[];
    maternal: Person[];
  };
}

And a corresponding variable representing the family instance:

const family: Family = {
  parents: [
    { firstName: "John", lastName: "Doe", age: 40 },
    { firstName: "Jane", lastName: "Doe", age: 38 },
  ],
  grandparents: {
    paternal: [
      { firstName: "PaternalGrandfather", lastName: "Doe", age: 70 },
      { firstName: "PaternalGrandmother", lastName: "Doe", age: 68 },
    ],
    maternal: [
      { firstName: "MaternalGrandfather", lastName: "Smith", age: 75 },
      { firstName: "MaternalGrandmother", lastName: "Smith", age: 72 },
    ],
  }
};

In order to provide means of immutability, we could write a generic, which recursively traverses and interface field and marks everything it encounters as Readonly, essentially mimicking the freezing, but eliminating the fuss of the actual deep freeze.

type DeepReadonly<T> = Readonly<{
  [K in keyof T]: 
    // Is it a primitive? Then make it readonly
    T[K] extends (number | string | symbol) ? Readonly<T[K]> 
    // Is it an array of items? Then make the array readonly and the item as well
    : T[K] extends Array<infer A> ? Readonly<Array<DeepReadonly<A>>> 
    // It is some other object, make it readonly as well
    : DeepReadonly<T[K]>;
}>

There, now we can create objects, which can be real constants:

const family2: DeepReadonly<Family> = {
  parents: [
    { firstName: "John", lastName: "Doe", age: 40 },
    { firstName: "Jane", lastName: "Doe", age: 38 },
  ],
  grandparents: {
    paternal: [
      { firstName: "PaternalGrandfather", lastName: "Doe", age: 70 },
      { firstName: "PaternalGrandmother", lastName: "Doe", age: 68 },
    ],
    maternal: [
      { firstName: "MaternalGrandfather", lastName: "Smith", age: 75 },
      { firstName: "MaternalGrandmother", lastName: "Smith", age: 72 },
    ],
  }
};

Any changes to the object typed with the generic are going to be stopped by the compiler:

family.parents = []; // ok
family2.parents = []; // error

family.parents[0].age = 1; // ok
family2.parents[0].age = 1; // error

// ok
family.parents.push({
  age: 40,
  firstName: 'Joseph',
  lastName: 'Doe'
});

// error
family2.parents.push({
  age: 40,
  firstName: 'Joseph',
  lastName: 'Doe'
});

All benefits from Object.freeze without a single freeze, cool, eh? At this point you are probably wondering how to shoot yourself in the foot with it, there should be a way.

And there is a way indeed, shooting in the foot is possible using reference types:

const family3: DeepReadonly<Family> = family;

As you remember, family is just Family, so any changes to it would mutate family3, even though it is deep readonly.

This is the way things are.

Hope you enjoyed the article as much as I did while researching this :)

The playground.

P.S. if someone knows how to pull this trick with generics in JSDoc, please post it in the comments :)
P.P.S. JSDoc conversion by @artxe2 so I don't lose it.

Safe Route Param Injection in Angular with a Decorator

Volodymyr Yepishev — Sat, 22 Jul 2023 15:32:52 +0000

The intro and last passage of this article were provided by ChatGPT, who(?) was the first one to read the article and provide feedback.

The final code for this article is available at github (since code fragments here are screenshots)

Route changes can have serious consequences in large Angular applications, and sometimes cause ripple effects and hidden bugs. When working with route parameters, it's crucial to ensure safety and maintainability in the codebase. In this article, we will delve into a powerful technique that leverages TypeScript's type-checking capabilities and a custom decorator to enhance the safety of extracting route parameters in Angular.

Traditionally, developers have relied on loosely defined strings for route parameters, which can lead to potential bugs and errors. In this article, we'll address this concern by introducing a more robust approach. We'll explore how TypeScript's static typing can be utilized to extract parameters accurately and enable intelligent code completion.

To further elevate safety, we'll implement a custom decorator that leverages the power of observables. This decorator will seamlessly inject route parameters into properties, ensuring a clean and type-safe approach throughout our Angular components.

By the end of this article, you'll have a deep understanding of this technique and be equipped with the knowledge to implement safe route param injection in your Angular projects. Let's embark on this journey to enhance safety and maintainability in our Angular applications.

Checking the classic Angular hall of heroes tutorial one can observe a code fragment dealing with getting hero id from route params in hero details component, which reads as follows:

// src/app/hero-detail/hero-detail.component.ts
  constructor(
    private route: ActivatedRoute,
    private heroService: HeroService,
    private location: Location
  ) {}

  ngOnInit(): void {
    this.getHero();
  }

  getHero(): void {
    const id = parseInt(this.route.snapshot.paramMap.get('id')!, 10);
    this.heroService.getHero(id)
      .subscribe(hero => this.hero = hero);
  }

With the app-routing.module.ts providing the following information about routes:

// src/app/app-routing.module.ts

const routes: Routes = [
  { path: '', redirectTo: '/dashboard', pathMatch: 'full' },
  { path: 'dashboard', component: DashboardComponent },
  { path: 'detail/:id', component: HeroDetailComponent },
  { path: 'heroes', component: HeroesComponent }
];

What are the points which can be improved here? The first one is, of course, loose strings in paths: there is no explicit connection between the :id in the path to the details component and the id grabbed from the params in the component. Should it become 'heroId', something migh break silently.

Let us discover how typescript can be used to increase the safety of extracting params from route, so only the existing params can be extracted, and also, how a decorator can be used for this purpose. Therefore, what we are aiming at, is having heroId$ as an Observable, injected into the hero details component via decorator.

Since a decorator is a function, it is a bit tricky to have it access Router or ActivatedRoute, however, it is possible: if APP_INITIALIZER were to be used to pass those references to our decorator, this could do the trick. However, there is a problem with this approach, as property decorators would fire prior to APP_INITIALIZER, which means we need the references before we can get them. To counter this we need something that can be available right away for subscription and which would serve as a channel to pass url params, so we need a BehaviorSubject, which will be used to broadcast params from the Router, which is to be injected later with APP_INITIALIZER. Consider the following code fragment:

import { NavigationEnd, Router } from '@angular/router';
import { BehaviorSubject } from 'rxjs';
import { filter, map } from 'rxjs/operators';

const params$ = new BehaviorSubject<Record<string, string>>({});

export function routeInitializer(router: Router): () => Promise<any> {
  return () =>
    new Promise<void>((resolve) => {
      router.events
        .pipe(filter((event) => event instanceof NavigationEnd))
        .subscribe(() => {
          params$.next(
            router.routerState.snapshot.root.firstChild?.params ?? {}
          );
        });

      resolve();
    });
}

Now we have a broadcasting channel which we can use inside a function, even before it starts receiving any events from the Router, we would just need to keep our decorator function in this file, so it has the access to it.

The time has come for some typescript kung fu, w are going to write a generic to extract parameters from a string, we know that paths cannot start with a forward slash and parameters are preceded by a column, therefore a generic to extract them would look as follows:

type PathParameter<T extends string> = T extends `:${infer P}/${infer R}`
  ? P | PathParameter<`${R}`>
  : T extends `${infer _}/${infer R}`
  ? PathParameter<`${R}`>
  : T extends `:${infer P}`
  ? P
  : unknown;

Works like a charm, now we have intellisense on our side:

const param: PathParameter<':path/:userId/:id/:name/profile/:profileId'> = 'id';

The next thing would be swapping loose strings for consonants and using those in paths instead:

// src/app/routes.const.ts
export const ROUTES = <const>{
  DASHBOARD: 'dashboard',
  DETAIL: 'detail/:id',
  HEROES: 'heroes',
};

// src/app/app-routing.module.ts
const routes: Routes = [
  { path: '', redirectTo: ROUTES.DASHBOARD, pathMatch: 'full' },
  { path: ROUTES.DASHBOARD, component: DashboardComponent },
  { path: ROUTES.DETAIL, component: HeroDetailComponent },
  { path: ROUTES.HEROES, component: HeroesComponent },
];

What is left now is to write a simple decorator function to do the param injections into a property, which it will receive from the params$ BehaviorSubject, created earlier:

export function param<T extends string>(parameter: PathParameter<T>) {
  return (target: any, propertyKey: string) => {
    target[propertyKey] = params$.asObservable().pipe(
      map((p) => p[<string>parameter]),
      filter(Boolean)
    );
  };
}

Viola, now we have a safe decorator for parameter injections, which can be used in the hero details component as following:

  @param<typeof ROUTES.DETAIL>('id')
  heroId$!: Observable<number>;

  constructor(private heroService: HeroService, private location: Location) {}

  ngOnInit(): void {
    this.getHero();
  }

  getHero(): void {
    this.heroId$
      .pipe(
        first(),
        switchMap((id) => this.heroService.getHero(id))
      )
      .subscribe((hero) => (this.hero = hero));
  }

Simple, isn't it?

With this newfound knowledge, you are now empowered to take your Angular applications to new heights of safety and maintainability. Happy coding!