DEV Community: YCM Jason

TypeScript Mutually Exclusive Unions: From `?: never` to `ExclusifyUnion`

YCM Jason — Thu, 06 Nov 2025 22:02:35 +0000

Mutually Exclusive Unions in TypeScript (and why `ExclusifyUnion` rocks)

When modelling data, we often want either one shape or another, never both at once. This is the essence of a mutually exclusive union. In TypeScript, that means writing unions where accessing properties becomes ergonomic without defensive checks everywhere.

This post shows a neat pattern using ?: never, why it doesn’t scale, and how type-fest’s ExclusifyUnion helper elegantly solves this problem.

The basic problem

Mutually exclusive unions help us distinguish the shape of a given object. Take the following example:

type Dog = {
  bark: () => void;
};

type Cat = {
  meow: () => void;
};

const vocalize = (animal: Dog | Cat) => {
  if ("bark" in animal) {
    animal.bark();
    return;
  }

  return animal.meow();
};

Once we’ve checked that bark or meow exists on animal, TypeScript narrows the union and everything is fine.

But the ergonomics in vocalize aren’t ideal. Intuitively, we’d love to destructure and call whichever function exists:

const vocalize = ({ bark, meow }: Dog | Cat) => {
  //                ^     ^
  // Property 'meow' does not exist on type 'Dog | Cat'.
  // Property 'bark' does not exist on type 'Dog | Cat'.
  return (bark ?? meow)();
};

TypeScript complains because you’re trying to access bark or meow before the union has been narrowed.

The `?: never` trick

A common workaround is to add the other member’s exclusive properties as ?: never. This hints to the type system that a property might be accessed, even if it doesn’t exist on this branch, so narrowing through destructuring becomes possible.

type Dog = {
  bark: () => void;
  meow?: never;
};

type Cat = {
  bark?: never;
  meow: () => void;
};

const vocalize = ({ bark, meow }: Dog | Cat) => {
  return (bark ?? meow)();
};

Now destructuring works, and TypeScript still understands that exactly one of bark or meow exists at a time (an exclusive-or).

Scaling This Pattern

The ?: never trick is fine for small unions, but it quickly becomes tedious when you introduce more types, each with many unique fields. Imagine adding more animals:

type Dog = {
  bark: () => void;
  wagTail: () => void;
  fetch: (item: string) => void;
  guard: () => void;

  // Cat props
  meow?: never;
  purr?: never;
  hiss?: never;

  // Bird props
  chirp?: never;
  fly?: never;
};

type Cat = {
  meow: () => void;
  purr: () => void;
  hiss: () => void;

  // Dog props
  bark?: never;
  wagTail?: never;
  fetch?: never;
  guard?: never;

  // Bird props
  chirp?: never;
  fly?: never;
};

type Bird = {
  chirp: () => void;
  fly: () => void;

  // Dog props
  bark?: never;
  wagTail?: never;
  fetch?: never;
  guard?: never;

  // Cat props
  meow?: never;
  purr?: never;
  hiss?: never;
};

Now we’re manually repeating a growing list of ?: never properties for every new type. As the union grows, maintaining all these exclusions becomes a nightmare of boilerplate.

Introducing `ExclusifyUnion`

This is exactly where type-fest’s ExclusifyUnion comes in (which I originally proposed here). It automates the process of adding ?: never based on your union type.

With ExclusifyUnion, you can keep your types clean and simple:

type Dog = {
  bark: () => void;
  wagTail: () => void;
  fetch: (item: string) => void;
  guard: () => void;
};

type Cat = {
  meow: () => void;
  purr: () => void;
  hiss: () => void;
};

type Bird = {
  chirp: () => void;
  fly: () => void;
};

const interact = (
  { fetch, chirp }: ExclusifyUnion<Dog | Cat | Bird>,
  thing: string,
) => {
  return (fetch ?? chirp)?.(thing);
};

That’s it. No manual exclusions, no verbosity, just clean, exclusive union types that work.

A familiar example: Zod’s `safeParse`

Zod’s safeParse result is a mutually exclusive union shaped to be ergonomic without extra checks. Conceptually:

type SafeParseResult<T> =
  | { success: true; data: T }
  | { success: false; error: Error };

In Zod, the types are defined more strictly to allow destructuring:

export type ZodSafeParseSuccess<T> = {
  success: true;
  data: T;
  error?: never;
};

export type ZodSafeParseError<T> = {
  success: false;
  data?: never;
  error: Error;
};

export type ZodSafeParseResult<T> =
  | ZodSafeParseSuccess<T>
  | ZodSafeParseError<T>;

Which enables this pattern:

const f = (x: unknown) => {
  const { data, error } = z.string().safeParse(x);

  if (!error) {
    data; // string
  }
};

Key Takeaways

Mutually exclusive shapes help TypeScript distinguish object structures cleanly. For example:
```
type Dog = {
  bark: () => void;
};

type Cat = {
  meow: () => void;
};
```
These ensure that only one of the two shapes applies at any given time.
Adding prop?: never to the opposite properties gives you ergonomic access to any properties without confusing TypeScript’s type narrowing.:
```
type Dog = {
  bark: () => void;
  meow?: never;
};

type Cat = {
  bark?: never;
  meow: () => void;
};
```
However, this approach doesn’t scale when your union includes many types or each type has many unique fields. The boilerplate grows fast.
type-fest’s ExclusifyUnion solves this elegantly, combining the clarity of clean domain types with the convenience of destructuring. It automatically enforces exclusivity across union members—no more repetitive ?: never definitions.

Introducing @ts-migrating: The Best Way To Upgrade Your TSConfig

YCM Jason — Mon, 23 Jun 2025 12:13:34 +0000

🚀 TypeScript is evolving fast, and your tsconfig should keep up. But upgrading TypeScript settings like strict, noUncheckedIndexedAccess, or erasableSyntaxOnly often means dealing with hundreds of type errors across your codebase.

That’s why I built @ts-migrating, a plugin and CLI tool that helps you progressively upgrade your tsconfig.json without breaking your codebase or your team's velocity.

😩 The Pain of Upgrading `tsconfig`

When you switch on a stricter compiler option, you immediately see a flood of new type errors. It is overwhelming. Realistically, your team does not have the time to fix everything in one go, and trying to do so is a recipe for burnout and regressions.

So what do people do?

They either:

Delay the upgrade indefinitely
Use @ts-ignore or @ts-expect-error as a blanket patch

But both approaches are flawed. You either never improve your codebase, or you sweep problems under the rug, sometimes even hiding unrelated bugs.

🧠 A Better Way: `@ts-migrating`

@ts-migrating lets you enable your desired compiler options now, while allowing problematic lines to fall back to the old config. It is TypeScript migration reimagined:

Show type errors introduced by the new config
Patch only the lines that are not ready using // @ts-migrating
Gradually fix those lines and remove the fallbacks over time

This plugin is designed to be incremental and safe. In fact, that is why it is called @ts-migrating, emphasising the ongoing process, not a one off migration.

Unlike @ts-ignore, which silences all errors on a line and can mask unrelated problems, @ts-migrating targets only those errors introduced by the new compilerOptions. This makes the intent of the directive clear, and keeps the rest of the line type safe.

🔌 How It Works

To install, simply run:

npm install -D ts-migrating

There are two parts to the tool:

1. Language Service Plugin

Add this to your tsconfig.json and your IDE will:

Show new errors introduced by the upgraded options
Allow you to silence specific lines with // @ts-migrating

{
  "compilerOptions": {
    "plugins": [
      {
        "name": "ts-migrating",
        "compilerOptions": {
          "noUncheckedIndexedAccess": true
        }
      }
    ]
  }
}

This plugin only affects IDEs and development. It has no impact on tsc or production builds.

2. CLI Tooling

There are 2 main commands for the standalone CLI.

Type check with the plugin

Since ts plugins have no effect on tsc, you can instead use the following in your terminal / CI.

npx ts-migrating check

This runs tsc with the plugin and reports all errors introduced by your new config.

Annotate your errors

npx ts-migrating annotate

This will insert // @ts-migrating above every new error line. Be careful. Run with a clean git state and review the changes.

🧪 Real Example: `noUncheckedIndexedAccess`

Here is a simple function:

function first(xs: number[]): number {
  return xs[0]; // error when `noUncheckedIndexedAccess: true`
}

With @ts-migrating, we can temporarily allow this line to fall back:

function first(xs: number[]): number {
  // @ts-migrating
  return xs[0]; // error disappear as this line now fall back to `noUncheckedIndexedAccess: false`
}

✅ Why You Should Use It

Avoid big bang migrations
Prevent new violations from sneaking in
Let your team upgrade progressively
No build time impact
Clean, intentional code comments

🌟 Ready to Migrate?

ts-migrating helps you modernise your TypeScript setup without turning your codebase into a war zone.

You can find the project here:
👉 github.com/ycmjason/ts-migrating

If you like the idea, give the repo a star, try it in your project, and let me know how it goes.

And if you would like to support this work, consider becoming a GitHub Sponsor. Every bit helps.

Let us make tsconfig upgrades easy again.

7 Modern Use Cases of IIFE

YCM Jason — Fri, 23 May 2025 16:04:28 +0000

In the last article, I introduced the try-catch IIFE pattern. Some of you found it clever, while others couldn’t stand the syntax. And honestly? Fair. IIFE (Immediately Invoked Function Expression) can look odd at first glance.

But I’m here to change your mind.

IIFE isn’t just a relic of the var era, there are still many modern use cases.

Here are 7 modern use cases of IIFE that go beyond legacy code and show how they can improve clarity, encapsulation, and expressiveness in your everyday code.

⏳ What Is an IIFE? (And Why Was It Essential in the `var` Era?)

Before we look at modern use cases, let’s rewind a bit.

IIFE stands for Immediately Invoked Function Expression. It's a function that runs right after it’s defined. Like this:

(() => {
  console.log("Hello!");
})();

You define a function and immediately invoke it. But why go through this strange ritual?

Well, back in the var era, var was the only way to define variables. It is function-scoped, unlike const and let which are block-scoped. So, variables declared inside for loops, if / switch statements weren’t isolated — they leaked into the surrounding scope.

Here’s an infamous example:

var buttons = [];

for (var i = 0; i < 3; i++) {
  buttons[i] = function () {
    console.log(i);
  };
}

buttons[0](); // 3
buttons[1](); // 3
buttons[2](); // 3

Surprise! They all log 3. That’s because var i was shared across all iterations!

To fix this, devs discovered a clever trick: wrap each loop iteration in an IIFE:

for (var i = 0; i < 3; i++) {
  (function (lockedInIndex) {
    buttons[lockedInIndex] = function () {
      console.log(lockedInIndex);
    };
  })(i);
}

Now it works as expected:

buttons[0](); // 0
buttons[1](); // 1
buttons[2](); // 2

This worked because each IIFE created a new function scope, capturing the correct value of i in each iteration.

Ben Alman wrote a seminal article on this pattern back in 2010 — it was so important that he helped define the term IIFE and documented all the ways to write one correctly. Check out his article here.

He even clarified the distinction between function declarations and expressions, which tripped up countless developers at the time. The () around the function weren’t for nothing! They were crucial so that the function is treated as an expression, allowing it to be executed immediately.

In short:

Without let and const, IIFE was the only way to get around problems with function scoping.
It became a powerful tool for encapsulation, module patterns, closures, and safe variable use.

Nowadays, we have proper block scoping via let and const. So IIFE has started to fade out from our memories.

...but that doesn’t mean it’s useless. As you’ll see below, IIFE still unlocks structure, encapsulation, and readability in surprisingly modern contexts.

Let’s dive in.

Use Case 1: Enable `async/await`

Ever tried using await in a place where you're not allowed to write async directly, like inside the useEffect hook in React?

If you've ever tried to do something like this:

useEffect(async () => {
  const response = await MyAPI.getData(someId);
  // ...
});

You are probably no stranger to this error message:

The recommended way to fix this is to define an async function in your effect and call it immediate. And guess what a function that is called immediately is? An IIFE!

The example code in the error message recommends you to do:

useEffect(() => {
  const fetchData = async () => {
    const response = await MyAPI.getData(someId);
    // ...
  }
  fetchData();
});

But why bother naming the function that is only used once? Naming is well-known to be one of the hardest thing in programming, if not the hardest. So do yourself a favour, skip the naming and just use IIFE:

useEffect(() => {
  (async () => {
    const response = await MyAPI.getData(someId);
    // ...
  })();
});

Use Case 2: `const` with `switch`

Sometimes switch statements are used just to initialise a variable.

Let's check out this real example from React:

let postTaskPriority;
switch (priorityLevel) {
  case ImmediatePriority:
  case UserBlockingPriority:
    postTaskPriority = 'user-blocking';
    break;
  case LowPriority:
  case NormalPriority:
    postTaskPriority = 'user-visible';
    break;
  case IdlePriority:
    postTaskPriority = 'background';
    break;
  default:
    postTaskPriority = 'user-visible';
    break;
}

// `postTaskPriority` is never reassigned again, but it is a `let`! 😢

The variable is never reassigned, yet we’re forced to use let because the value is assigned inside the switch.

With IIFE:

const postTaskPriority = (() => {
  switch (priorityLevel) {
    case ImmediatePriority:
    case UserBlockingPriority:
      return 'user-blocking';
    case LowPriority:
    case NormalPriority:
      return 'user-visible';
    case IdlePriority:
      return 'background';
    default:
      return 'user-visible';
  }
})();

// `postTaskPriority` can NEVER be reassigned again, because it is a `const`! 🎉

No let. No risk of accidental reassignment. And we even skip all the break statements! HUGE WIN!

You can also apply the same pattern to if statements. Here’s a real-world example from Angular:

let kind: DisplayInfoKind;
if (symbol.kind === SymbolKind.Reference) {
  kind = DisplayInfoKind.REFERENCE;
} else if (symbol.kind === SymbolKind.Variable) {
  kind = DisplayInfoKind.VARIABLE;
} else if (symbol.kind === SymbolKind.LetDeclaration) {
  kind = DisplayInfoKind.LET;
} else {
  throw new Error(
    `AssertionError: unexpected symbol kind ${SymbolKind[(symbol as Symbol).kind]}`,
  );
}

With IIFE:

const kind = (() => {
  if (symbol.kind === SymbolKind.Reference) {
    return DisplayInfoKind.REFERENCE;
  }

  if (symbol.kind === SymbolKind.Variable) {
    return DisplayInfoKind.VARIABLE;
  }

  if (symbol.kind === SymbolKind.LetDeclaration) {
    return DisplayInfoKind.LET;
  }

  throw new Error(
    `AssertionError: unexpected symbol kind ${SymbolKind[(symbol as Symbol).kind]}`,
  );
})();

Clean, top-down logic. Guard clauses instead of nested else-ifs. And as a bonus, no need explicitly type kind as TypeScript infers the type for free!

Use Case 3: Inline Guard Clauses

Ever had to chain multiple ternary operators in your code?

Here's a code snippet from Vue.js:

const defer =
  typeof process !== 'undefined' && process.nextTick
    ? process.nextTick
    : typeof Promise !== 'undefined'
    ? fn => Promise.resolve().then(fn)
    : typeof setTimeout !== 'undefined'
    ? setTimeout
    : noop

Multiple chain of ternary operators can become unreadable very quickly. With IIFE:

const defer = (() => {
  if (typeof process !== 'undefined' && process.nextTick) {
    return process.nextTick;
  }

  if (typeof Promise !== 'undefined') {
    return fn => Promise.resolve().then(fn);
  }

  if (typeof setTimeout !== 'undefined') {
    return setTimeout;
  }

  return noop;
})();

It is so much cleaner, right?

Each branch is clear, readable, and obvious. You can instantly see there are three conditions and a default fallback to noop.

Use Case 4: Stateful Functions

Let’s say you need a function that tracks its own state:

let nextCount = 0;
const getNextCount = () => nextCount++;

But nextCount is exposed to the whole file now! Anyone can modify it and it comes down to trusting developers and your future self not to mess with it!

Now try:

const getNextCount = (() => {
  let nextCount = 0;
  return () => nextCount++;
})();

Fully encapsulated. No accidental modifications.

Use Case 5: Object Property Initialisation

IIFE can be used to create a more encapsulated object construction pattern.

I came across this piece of code from Angular:

export async function generateMetadata(
  path: string,
  config: TutorialConfig,
  files: FileAndContentRecord,
): Promise<TutorialMetadata> {
  const tutorialFiles: FileAndContentRecord = {};
  const {dependencies, devDependencies} = JSON.parse(
    files['package.json'] as string,
  ) as PackageJson;

  config.openFiles?.forEach((file) => (tutorialFiles[file] = files[file]));

  return {
    type: config.type,
    openFiles: config.openFiles || [],
    allFiles: Object.keys(files),
    tutorialFiles,
    answerFiles: await getAnswerFiles(path, config, files),
    hiddenFiles: config.openFiles
      ? Object.keys(files).filter((filename) => !config.openFiles!.includes(filename))
      : [],
    dependencies: {
      ...dependencies,
      ...devDependencies,
    },
  };
}

Pretty standard pattern. We do some setup — in this case, computing tutorialFiles and parsing dependencies — and then use them in the returned object.

But the setup code can get mixed up really easily and the setup and the usage of the setup are in 2 completely different places!

With IIFE, we can keep each property's setup and usage within its own function:

export async function generateMetadata(
  path: string,
  config: TutorialConfig,
  files: FileAndContentRecord,
): Promise<TutorialMetadata> {
  return {
    type: config.type,
    openFiles: config.openFiles || [],
    allFiles: Object.keys(files),
    tutorialFiles: (() => {
      const tutorialFiles: FileAndContentRecord = {};
      config.openFiles?.forEach((file) => (tutorialFiles[file] = files[file]));
      return tutorialFiles;
    })(),
    answerFiles: await getAnswerFiles(path, config, files),
    hiddenFiles: config.openFiles
      ? Object.keys(files).filter(
          (filename) => !config.openFiles!.includes(filename),
        )
      : [],
    dependencies: (() => {
      const { dependencies, devDependencies } = JSON.parse(
        files["package.json"] as string,
      ) as PackageJson;

      return {
        ...dependencies,
        ...devDependencies,
      };
    })(),
  };
}

Use Case 6: Try-Catch IIFE

Go check out my previous article to learn more.

But basically:

const user = (() => {
  try {
    return await getUser();
  } catch (err) {
    // handle err
    return null;
  }
})();

Use Case 7: Hierarchies of Abstraction

Sometimes our code can look very flat even when semantically there should be some sort of hierarchies:

const getPosition = (...) => {
  const a = ...
  const b = ...
  const x = getX(a, b);

  const c = ...
  const d = ...
  const y = getY(c, d);

  return [x, y];
};

In this example, the hierarchy look something like this:

With IIFE, we can visually represent such hierarchy:

const getPosition = (...) => {
  const x = (() => {
    const a = ...
    const b = ...
    return getX(a, b);
  })();

  const y = (() => {
    const c = ...
    const d = ...
    return getY(c, d);
  })();

  return [x, y]
};

It is clear, encapsulated, and easy to zoom in and out of the logic without friction.

Final Thoughts

Despite being a pattern born in the early days of JavaScript, IIFE still earns its place in modern development. It’s no longer something we have to use — and that’s precisely what makes it powerful.

When you choose to use IIFE today, you’re doing it for structure, clarity, and intent. You’re declaring, “this bit of logic is self-contained and intentional.” Whether it's to enable async/await, protect internal state, or express a hierarchy of abstraction, IIFE gives you an extra layer of control over your code.

Sure, it can be noisy — but in the right places, it can be beautiful.

So the next time you reach for a let just because switch says so… maybe, just maybe, give IIFE another look.

Let me know what you think — I’d love to hear your thoughts!

TRY {} CATCH {} ‒ FIXED! (with a surprisingly old trick)

YCM Jason — Sat, 10 May 2025 08:30:48 +0000

This article is loosely based off my recent video:

Hey everyone, Jason here 👋

Let's talk about something that many JavaScript developers love to hate: try-catch.

In this article, I want to explore:

why try-catch can be frustrating
discuss a common solution many have proposed, and
introduce a pattern that I haven't seen enough people talk about

The Problem with try-catch

Consider this function:

function getUserAndPreference() {
  try {
    const user = getUser();
    const preference = getUserPreference(user);
    return [user, preference];
  } catch (error) {
    return null;
  }
}

At first glance, this seems fine. But here's the issue: the try block catches all errors within it. That means if getUser or getUserPreference throws an error, or even if there's a typo elsewhere, they all get caught in the same catch block. This makes debugging and maintenance harder as your function grows.

To handle errors more granularly, you might consider wrapping each operation in its own try-catch:

function getUserAndPreference() {
  let user: User;
  try {
    user = getUser();
  } catch (error) {
    return null;
  }

  let preference: UserPreference;
  try {
    preference = getUserPreference(user);
  } catch (error) {
    return null;
  }

  return [user, preference];
}

But this pattern has its own issues:

Forced to use let instead of const This pattern requires us to declare the variables and assign them in different scope. This forces us to replace our "supposedly" const to let.
Forced to use explicit typing In the previous example, all variables are typed automatically thanks to TypeScript's type inference. However, this approach forces us to seperate the declaring and assigning of the variables, meaning that TypeScript couldn't determine the variables types at declaration and use implicit any for those variables!

To summarize, the 3 pain-points of try-catch are:

Catch-all behaviour
Forcing let instead of const
Compromising type inference by TypeScript

The "Do Not Throw" Pattern

To address these issues, many developers advocate for a "do not throw" approach. Instead of throwing errors, functions return a tuple containing the error and the result.

Here's a really simple example of such concept:

const tryCatch = async <T>(
  promise: Promise<T>,
): Promise<[error: null, result: T] | [error: Error]> => {
  try {
    return [null, await promise];
  } catch (error) {
    return [error];
  }
};

Usage:

const [error, user] = await tryCatch(getUser());
if (error) {
  // handle error
}

This pattern mitigates all 3 issues mentioned in the previous section: allows for more granular error handling, allows for using const, and still keep TypeScript's type inference.

However, I find it not to be the most idiomatic way to JavaScript (handling errors as return values) and requires a utility function that's not standardized which causes never-ending discussions amongst engineers with different background and preferences.

Enter IIFE: Immediately Invoked Function Expression

IIFE, pronounced as Eevee (the Pokémon), is a pattern that's been around since the earliest days of JavaScript.

const user = await (async () => {
  try {
    return await getUser();
  } catch (error) {
    return null;
  }
})();

By wrapping the operation in an IIFE, we can use try-catch as usual while eliminating all problems with try-catch mentioned previously.

We can apply the same pattern to getUserPreference:

const preference = await (async () => {
  try {
    return await getUserPreference(user);
  } catch (error) {
    return null;
  }
})();

Now, our function looks like this:

async function getUserAndPreference() {
  const user = await (async () => {
    try {
      return await getUser();
    } catch (error) {
      return null;
    }
  })();

  if (!user) return null;

  const preference = await (async () => {
    try {
      return await getUserPreference(user);
    } catch (error) {
      return null;
    }
  })();

  if (!preference) return null;

  return [user, preference];
}

This approach allows for granular error handling, maintains code integrity, and leverages type inference—all without any utility functions.

Looking Ahead: Do Expressions

There's a proposal for "do expressions" in JavaScript, currently at stage 1. It aims to bring similar functionality as IIFE but with cleaner syntax:

const getUserAndPreference = async () => {
  const user = do {
    try {
      getUser();
    } catch (error) {
      // handle errors here
      return null; // return from getUserAndPreference
    }
  };
  // ...
};

Once this proposal is accepted as the language standard, try-catch IIFEs can migrate seamlessly to do expressions.

Final Thoughts

try-catch isn't inherently evil. It's how we use it that matters. By leveraging IIFE, we can write cleaner, more maintainable code without relying on external utilities or compromising code integrity.

I hope you found this helpful! If you did, please like, give me a follow, and share with your friends. If you have any questions or ideas, feel free to comment and let me know.

Let me know if you'd like to explore more patterns or have any questions!

[Boost]

YCM Jason — Fri, 07 Feb 2025 18:44:17 +0000

I Recreated Tom Riddle’s Diary, But Used My Soul Instead 👻

YCM Jason ・ Feb 6

#webdev #ai

I Recreated Tom Riddle’s Diary, But Used My Soul Instead 👻

YCM Jason — Thu, 06 Feb 2025 23:36:38 +0000

YCMJason's Diary 📖✨

This web app is inspired by Tom Riddle's Diary. I've literally enchanted this website with a piece of my soul 🪄🖤. So go ahead, talk to it, and learn more about me!

🔗 YCMJason's Diary 🌍✨
🔗 GitHub Repo

Here are some quick write up on some of the challenges I faced in this project.

This project had two major challenges:

Recognizing handwriting ✍️
Running an LLM for free 💸

Recognizing Handwriting ✍️

A Tom Riddle Diary wannabe that only accepts keyboard input? Absolutely unacceptable! 😤 So I set out to implement handwriting recognition on a canvas.

The Journey:

Tesseract.js 🤖
- Great for printed text ✅
- Absolute trash for handwriting ❌
Transformers.js by 🤗 Hugging Face
- Looked promising...
- Required users to download huge models (~30s load time 😭)
- Recognition results? Not even close! ❌
The Breakthrough: Handwriting.js 🔍
- BOOM! Found this hidden gem: handwriting.js 💎
- How does it work? 🤯 It reverse-engineers Google's IME by sending stroke data to Google's API: 👉 https://www.google.com/inputtools/request?ime=handwriting&app=mobilesearch&cs=1&oe=UTF-8
- Results are blazingly fast ⚡ and super accurate 🎯!

👨‍🔧 But the project was 5 years old and looked like it was built in 2003... 😬 So I ~~stole~~ borrowed the core logic and rewrote it in modern JavaScript! Might publish it on JSR later if there’s demand! 🚀 Let me know if you're interested! 💬

Running an LLM for Free 💸

For the LLM, I remembered this awesome project: mlc-webllm, which runs models directly on your device! 🔥

The Journey:

MLC-WebLLM ✅
- Model download time: 🚦 30+ seconds (Users will leave after 5 seconds, let's be real 😅)
- Inference speed:
- M1 Max MacBook: 5 seconds ⏳
- Pixel 9 Pro Fold: 30+ seconds 🚨
- Turns out, my system prompt was the culprit! 😱 Longer prompts slow down inference a lot.
Transformers.js ❌
- Even slower than MLC-WebLLM 😭
- Downloads the model in a single request without batching (or so it seems 🤔)
The Breakthrough: OpenRouter + Vercel AI SDK 🎯
- Found a GitHub list of free LLM APIs 🏆
- Settled on OpenRouter and paired it with Vercel’s AI SDK
- Final result? Super smooth UX & fast responses! 🚀

🚀 The dev experience? Absolute chef's kiss 👨‍🍳👌. Huge thanks to Vercel & OpenRouter! 🙌

Final Thoughts 🧠

If this app doesn’t go viral, I’ll be sad. 😢 So please, go have fun with it! 🎉

💬 Feedback? File an issue or ping me on X or 🦋.

Advanced Typescript: Typing Partially Applicable Functions

YCM Jason — Fri, 02 Jun 2023 11:53:43 +0000

This post follows up on How to make functions partially applicable in JavaScript.

Partial Function Application allows functions to collect its arguments in multiple function calls, returning the result once all arguments are collected. For example, f(x, y, z) can be called as f(x)(y, z) or f(x, y)(z) etc.

Some people might confuse this with currying. However, currying is a slightly different concept as it only refers to turning a function with N arguments into N functions that takes in 1 argument. E.g. f(x, y, z) into f(x)(y)(z).

In this article, we will explore how we can define the type PartiallyApplicable<F> that would allow F to be applied partially.

TL; DR

// basically dropping the last element until we have exactly 1 element, this keeps the label of the array
type GetFirstParam<Params extends any[]> = Params extends [any]
  ? Params
  : Params extends [...infer X, any]
  ? GetFirstParam<X>
  : never;

type GetRestParam<Params extends any[]> = Params extends [any, ...infer Rest]
  ? Rest
  : [];

type PrependArg<
  F extends (...args: any[]) => any,
  X extends [any]
> = F extends (...args: infer Args) => infer ReturnType
  ? (...rest: [...X, ...Args]) => ReturnType
  : never;

type PartiallyApplicableUnion<F extends (...payload: any[]) => any> =
  F extends (...args: infer Args) => infer ReturnV
    ? Args extends []
      ? F
      : Args extends [any]
      ? F | (() => PartiallyApplicable<F>)
      :
          | (() => PartiallyApplicable<F>)
          | ((
              ...args: GetFirstParam<Parameters<F>>
            ) => PartiallyApplicable<
              (...argRest: GetRestParam<Parameters<F>>) => ReturnV
            >)
          | PrependArg<
              PartiallyApplicableUnion<
                (...argRest: GetRestParam<Parameters<F>>) => ReturnV
              >,
              GetFirstParam<Parameters<F>>
            >
    : never;

type UnionToIntersection<U> = (
  U extends any ? (arg: U) => any : never
) extends (arg: infer I) => void
  ? I
  : never;

type PartiallyApplicable<F extends (...payload: any[]) => any> =
  UnionToIntersection<PartiallyApplicableUnion<F>>;

// Example:

// notice how the argument names are now preserved
declare const f: PartiallyApplicable<
  (a: number, b: string, c: boolean, d: Date) => string
>;

// all evaluates to string
f(0, 'a', true, new Date());
f(0)('a', true, new Date());
f(0, 'a', true)(new Date());
f()()(3)()('a', true)()()(new Date());

TS Playground

Recap: How to make functions partially applicable in JavaScript

In the previous article, we've explored how we can make any functions partially applicable.

const enablePartialApplication = (fn) => (...args) => {
    if (args.length >= fn.length) return fn(...args);
    return enablePartialApplication(fn.bind(null, ...args));
};

const f = enablePartialApplication((a, b, c) => a + b + c)
f(1)(2, 3) // 6
f(1, 2, 3) // 6
f(1, 2)(3) // 6
f(1)(2)(3) // 6

This function either return the result of fn, if the provided args matches the number of arguments fn accepts, or it returns a partially applicable function that takes in the rest of the arguments.

Goal of this article

The goal of this article is to present a step-by-step approach to tackle type challenges like this. The following sections are progressively more complicated, but my objective is to ensure that anyone can take away something valuable from this article, even if you don't fully comprehend the final conclusion.

Typing the `add` Function

Function overload is a way to define multiple call signature of a function. For example:

function add(x: number, y: number): number; // first overload
function add(x: number): (y: number) => number; // second overload
function add(x: number, y?: number): number | (y: number) => number {
  if (typeof y === "undefined") return (y: number) => x + y;
  return x + y;
}

add(1)(2); // using the first overload
add(1, 2); // using the second overload

In fact, function overload can be expressed with &. For example:

type Add = ((x: number, y: number) => number) &
  ((x: number) => (y: number) => number);

const add = ((x: number, y?: number): number | ((y: number) => number) => {
  if (typeof y === "undefined") return (y: number) => x + y;
  return x + y;
}) as Add;

Note that in here we need to use as Add since TypeScript wouldn't be able to figure out in which case the function returns a function or a number. In the following article, we will be using the latter syntax as it allows more flexible composition of function overloading.

Typing 2-ary Functions

A 2-ary function, also known as a binary function, is a function that takes exactly two inputs or arguments.

In this section, we'd define PartiallyApplicable2<F>:

type PartiallyApplicable2<F extends (x: any, y: any) => any> = ...

With this, we can simply define Add as PartiallyApplicable2<(x: number, y: number) => number>.

We can tackle this relatively easily. With the help of infer, we can define the type as

type PartiallyApplicable2<F extends (x: any, y: any) => any> = F extends (
  x: infer X,
  y: infer Y
) => infer R
  ? ((x: X, y: Y) => R) & ((x: X) => (y: Y) => R)
  : never;

type Add = PartiallyApplicable2<(x: number, y: number) => number>;

This is relatively simple. Here is a breakdown:

Inferring the argument and return types

 type PartiallyApplicable2<F extends (x: any, y: any) => any> = F extends (
   x: infer X,
   y: infer Y
 ) => infer R
   ? [if-case]
   : [else-case]

We know that F must be a function that takes in 2 argument and return something (based on the F extends (x: any, y: any) => any constraint), so we can put never in the [else-case].

 type PartiallyApplicable2<F extends (x: any, y: any) => any> = F extends (
   x: infer X,
   y: infer Y
 ) => infer R 
   ? [if-case]
   : never

In the [if-case], we know that there are 2 posible ways to call a 2-ary partially applicable function. You can either call the function with all 2 arguments or 1 after another. So we can simply put ((x: X, y: Y) => R) & ((x: X) => (y: Y) => R):
```
 type PartiallyApplicable2<F extends (x: any, y: any) => any> = F extends (
   x: infer X,
   y: infer Y
 ) => infer R
   ? ((x: X, y: Y) => R) & ((x: X) => (y: Y) => R)
   : never;
```

With PartiallyApplicable2 we can type any arbitrary 2-ary function easily.

Typing N-ary Function

In computer science, N-ary functions are commonly used to represent operations that take a variable number of arguments.

Typing 2-ary functions is easy. Let's take a step further and think about how we can create a general PartiallyApplicable<F> type that will facilitate any N-ary function.

Before we dive into any code, let's figure out what PartiallyApplicable<F> should do in from a 0-ary to 4-ary functions:

In the following, I would use some psudo-TypeScript to describe function signature. Specifically, (A, B) => R to represent (a: A, b: B) => R. This reduces noise and make things easier to understand.

For illustration purpose, I would ignore the case where you can pass no argument to the partially applicable function, except for the 0-ary function. We will discuss how to deal with this case in a later section.

0-ary function: PartiallyApplicable<() => R>
- There is only 1 way to call this function:
  1. () => R
1-ary function: PartiallyApplicable<(A) => R>
- There is only 1 way to call this function:
  1. (A) => R
2-ary function: PartiallyApplicable<(A, B) => R>
- 2 overloads:
  1. (A, B) => R
  2. (A) => (B) => R
3-ary function: PartiallyApplicable<(A, B, C) => R>
- 4 overloads:
  1. (A, B, C) => R
  2. (A, B) => (C) => R
  3. (A) => (B, C) => R
  4. (A) => (B) => (C) => R
4-ary function: PartiallyApplicable<(A, B, C, D) => R>
- 8 overloads:
  1. (A, B, C, D) => R
  2. (A, B, C) => (D) => R
  3. (A, B) => (C, D) => R
  4. (A, B) => (C) => (D) => R
  5. (A) => (B, C, D) => R
  6. (A) => (B, C) => (D) => R
  7. (A) => (B) => (C, D) => R
  8. (A) => (B) => (C) => (D) => R

As you can see, the number of overloads grows exponentially as the number of arguments goes bigger.

Here is an illustration of a 4-ary function:

Consider only the node: remaining: B, C, D and the paths involved.

In fact, this tree that's currently highlighted is exactly PartiallyApplicable<(B, C, D) => R>! It contains 4 "routes" to get to R, namely:

(B) => (C) => (D) => R
(B) => (C, D) => R
(B, C) => (D) => R
(B, C, D) => R

This gives us a clue that (A) => PartiallyApplicable<(B, C, D) => R> would define half of PartiallyApplicable<(A, B, C, D) => R>!

Now let's take a closer look to the left-hand side of the tree:

It actually shares most of the bits as the tree spanning from the node remaining: B, C, D. The only difference being the first call signature:

Notice the symmetry of the lines coming from node remaining: A, B, C, D and the node remaining: B, C, D. The minimum edit to get from the right 3 lines to the left 3 lines is to append (A, ...) to each line!

(B) becomes (A, B)
(B, C) becomes (A, B, C)
(B, C, D) becomes (A, B, C, D)

We will use an imaginary utility type (see latter section on how we define this) called PrependArg<F extends (...args: any[]) => any, X>, that will prepend X to the parameters of F. E.g. PrependArg<(A, B) => R, X> would equal to (X, A, B) => R.

Now, we can get the left-hand side of the tree by simply doing PrependArg<PartiallyApplicable<(B, C, D) => R>, A>. This should yield:

PrependArg<(B) => ..., A> will become (A, B) => ...
PrependArg<(B, C) => ..., A> will become (A, B, C) => ...
PrependArg<(B, C, D) => ..., A> will become (A, B, C, D) => ...

To conclude this section, we have discovered that PartiallyApplicable<(A, B, C, D) => R> is basically:

((A) => PartiallyApplicable<(B, C, D> => R>) &
PrependArg<PartiallyApplicable<(B, C, D) => R>, A>

In fact, this pattern applies to any N-ary functions, for N > 1. So we can generalise this and say PartiallyApplicable<(A, ...RestArgs) => R> equals to:

((A) => PartiallyApplicable<(...RestArgs> => R>)
    & (PrependArg<PartiallyApplicable<(...RestArgs) => R>, A>)

As with any recursive solution, we'd need a base case. In this case, it would simply be a 0-ary or 1-ary function. In which cases we can simply return the original function signature, as there is only 1 way to call them as discussed previously.

In psudo-TypeScript, the whole solution looks something like:

// not real TypeScript, skipping argument names for simplicity
type PartiallyApplicable<F extends (...any[]) => any> =
  F extends (...infer Args) => infer ReturnV
    ? Args extends [] | [any] // base case
      ? F // there is only 1 way to call it
      : Args extends [infer A, ...infer RestArgs] // recursive case
      ? ((A) => PartiallyApplicable<(...RestArgs) => ReturnV>)
          & PrependArg<PartiallyApplicableUnion<(...RestArgs) => ReturnV>, A>
      : never
    : never;

Implementing in TypeScript

In the previous section, we've come up with a recursive definition of PartiallyApplicable<F> using some psudo-TypeScript.

In this section, we are going to explore how we can implement it in TypeScript.

Let's start with PrependArg. It is quite simple:

type PrependArg<F extends (...args: any[]) => any, X> = F extends (
  ...args: infer A
) => infer R
  ? (x: X, ...args: A) => R
  : never;

This implementation works for union of functions. So PrependArg<() => number | (a: string) => void, boolean> would become ((x: boolean) => number) | (x: boolean, a: string) => void, but not intersection of functions.

In fact, Intersection & is very hard to manipulate in TypeScript, if not impossible. See here for an attempt to do so.

Since union types are much easier to manipulate, we can instead generate a union of all overload functions, then use UnionToIntersection<U>, a magical utility type, to turn A | B into A & B. UnionToIntersection<U> is too "trivial", so I won't dive into the details of it. Instead, I'll leave it as an exercise for you. 🤣 If you are interested, you can read more here.

type UnionToIntersection<U> = (
  U extends any ? (arg: U) => any : never
) extends (arg: infer I) => void
  ? I
  : never;

With this utility, our aim now is to define PartiallyApplicableUnion<F> which generates a union of all overload functions for a partially applicable F. We have roughly defined this using psudo-TypeScript previously, so let's translate that into TypeScript and have everything combined.

type PrependArg<F extends (...args: any[]) => any, X> = F extends (
  ...args: infer A
) => infer R
  ? (x: X, ...args: A) => R
  : never;

type PartiallyApplicableUnion<F extends (...payload: any[]) => any> =
  F extends (...args: infer Args) => infer ReturnV
    ? Args extends [] | [any]
      ? F
      : Args extends [infer Arg0, ...infer ArgRest]
      ?
          | ((
              arg0: Arg0
            ) => PartiallyApplicable<(...argRest: ArgRest) => ReturnV>)
          | PrependArg<
              PartiallyApplicableUnion<(...argRest: ArgRest) => ReturnV>,
              Arg0
            >
      : never
    : never;

Now all we have to do is:

type UnionToIntersection<U> = (
  U extends any ? (arg: U) => any : never
) extends (arg: infer I) => void
  ? I
  : never;

type PartiallyApplicable<F extends (...payload: any[]) => any> =
  UnionToIntersection<PartiallyApplicableUnion<F>>;

/* Correctly yields 4 call paths to get to the result: 
 * ((x: number, x: string, c: boolean) => number) 
 *     & ((x: number, arg0: string) => (c: boolean) => number)
 *     & ((arg0: number) => (
 *         (x: string, c: boolean) => number)
 *             & ((arg0: string) => (c: boolean) => number)
 *     )
 */
type F = PartiallyApplicable<(a: number, b: string, c: boolean) => number>

You can see the working code here.

Calling the Partially Applicable Function with No Arguments

To extend our implementation to support calls with no arguments, it's pretty simple. Our call tree for a 4-ary partially applicable function will become:

Basically calling the partially applicable function with ( ) should just simply return the same function. So we can simply add one more case to our recursive case and add support for 1-ary functions:

type PartiallyApplicableUnion<F extends (...payload: any[]) => any> =
  F extends (...args: infer Args) => infer ReturnV
    ? Args extends []
      ? F
      : Args extends [any]
      ? F | (() => PartiallyApplicable<F>) // allow calls with no arguments
      : Args extends [infer Arg0, ...infer ArgRest]
      ?
          | (() => PartiallyApplicable<F>) // allow calls with no arguments
          | ((
              arg0: Arg0
            ) => PartiallyApplicable<(...argRest: ArgRest) => ReturnV>)
          | PrependArg<
              PartiallyApplicableUnion<(...argRest: ArgRest) => ReturnV>,
              Arg0
            >
      : never
    : never;

Note that an 1-ary partially applicable function will now have 2 ways to call.

You can see the working version here.

Extended: Preserving argument names

Our current implementation works totally fine. But there is one thing that keeps it away from being perfect. That is, the argument names are not kept in the overload functions.

This is due to the way we infer our arguments. When we do F extends (x: infer X) => any, we would lose the argument name for X.

In TypeScript, argument names are basically stored in the label of array. So when you do Parameters<(a: number, b: number) => any>, you will get [a: number, b: number]. However, these label can't be easily retrieved.

Instead of retreiving the labels, what we could do is to avoid using infer, but keep track of the list at all times. Instead of [infer X, ...infer Rest], we would somehow retrieve the X as a list. We will also edit PrependArg<F, X> to take in X as an array too, so the label is passed down. Here is a way to do it:

// basically dropping the last element until we have exactly 1 element, this keeps the label of the array
type GetFirstParam<Params extends any[]> = Params extends [any]
  ? Params
  : Params extends [...infer X, any]
  ? GetFirstParam<X>
  : never;

type GetRestParam<Params extends any[]> = Params extends [any, ...infer Rest]
  ? Rest
  : [];

type PrependArg<
  F extends (...args: any[]) => any,
  X extends [any] // expect an array so the label is preserved
> = F extends (...args: infer Args) => infer ReturnType
  ? (...rest: [...X, ...Args]) => ReturnType
  : never;

type PartiallyApplicableUnion<F extends (...payload: any[]) => any> =
  F extends (...args: infer Args) => infer ReturnV
    ? Args extends []
      ? F
      : Args extends [any]
      ? F | (() => PartiallyApplicable<F>)
      :
          | (() => PartiallyApplicable<F>)
          | ((
              ...args: GetFirstParam<Parameters<F>>
            ) => PartiallyApplicable<
              (...argRest: GetRestParam<Parameters<F>>) => ReturnV
            >)
          | PrependArg<
              PartiallyApplicableUnion<
                (...argRest: GetRestParam<Parameters<F>>) => ReturnV
              >,
              GetFirstParam<Parameters<F>>
            >
    : never;

type UnionToIntersection<U> = (
  U extends any ? (arg: U) => any : never
) extends (arg: infer I) => void
  ? I
  : never;

type PartiallyApplicable<F extends (...payload: any[]) => any> =
  UnionToIntersection<PartiallyApplicableUnion<F>>;

// Example:

// notice how the argument names are now preserved
declare const f: PartiallyApplicable<
  (a: number, b: string, c: boolean, d: Date) => string
>;

// all evaluates to string
f(0, 'a', true, new Date());
f(0)('a', true, new Date());
f(0, 'a', true)(new Date());
f()()(3)()('a', true)()()(new Date());

You can find the fully working version here.

Limitations

This implementation has a few limitations and will not work for the following cases:

Functions with optional arguments
Functions with generics
Functions with variable argument length

Conclusion

In this article we have looked at how we can type partially applicable functions in TypeScript. We went through the patterns of partially applicable N-ary functions and spotted the recursive structure within it.

You might be wondering, why did I spend the time trying to solve this? Partial function application isn't that useful anyways. While it is true, I started looking into typing partially applicable functions because all functions in my favourite utility library Ramda are partially applicable.

However, in the type definitions, these partially applicable functions are explicitly typed with overflows (example). So the types end up being quite noisy and complicated over time. So I decided to take on this challenge of typing any N-ary functions to be partially applicable.

I hope you enjoyed reading this article. And if you have made it all the way here, congratulations and thank you for your time. I hope you've taken away somethings useful from this article. Please feel free to share your thoughts, or suggest any improvements you can think of. I'd be excited to hear from you.

Detecting barcode from the browser!!!

YCM Jason — Sat, 06 Nov 2021 23:46:56 +0000

Background

I have just arranged for my first ever concert that is going to happen in mid-December in Hong Kong. As I was sorting out the logistics for ticket sales, I decided to build a simple system for myself. People can go on the stripe payment link to purchase the ticket. Then a webhook will be triggered which generates an email with a QR code. The QR code then will be scanned for entry on the day of concert at the door. As I was looking for solution for QR code detection, I discovered this beautiful Barcode Detection API

I didn't see many tutorials about it yet, so I have decided to make a note about my exploration. Hope you will enjoy!

Article Synopsis

This article will split into 2 parts:

Getting feed from camera
Detect barcode from camera feed

Part 1: Getting feed from camera

In this section, our goal is to put the camera stream onto the page.

First, we need a <video> element to show the camera stream.

<video id="stream" style="width: 100vw; height: 100vh;" />

Then, we can simply use getUserMedia to grab the media stream; pass that stream directly to the video element.

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: { ideal: 'environment' }
  },
  audio: false
});
const videoEl = document.querySelector('#stream');
videoEl.srcObject = stream;
await videoEl.play();

Note that, the { ideal: 'environment' } option is provided so the back camera on a phone is used. Find out more here.

With these few lines of code, we capture the camera feed and displayed it on the screen. See codepen.

Part 2: Detect barcode from camera feed

The barcode detection api provides a simple API for barcode detection. All you need is new BarcodeDetector(...) then barcodeDetector.detect(videoElement).

So we will add these two lines:

/* code from part one */


const barcodeDetector = new BarcodeDetector({formats: ['qr_code']});
const barcodes = await barcodeDetector.detect(videoEl)

Now the barcode detector will be activated at the exact moment the video starts streaming. We probably won't expect to find any QR code at the moment people turn on their camera. So we will need to continuously look at the video stream and call .detect(...) until we got some barcodes.

In order to do that, we can .detect every X ms until we got some barcodes. Simply use window.setInterval for this.

/* code from part one */

const barcodeDetector = new BarcodeDetector({formats: ['qr_code']});
window.setInterval(async () => {
  const barcodes = await barcodeDetector.detect(videoEl);
  if (barcodes.length <= 0) return;
  alert(barcodes.map(barcode => barcode.rawValue));
}, 1000)

Now the camera will look for barcode every second! See codepen and try to load up a QR code to test! Here is an QR code for "hello world".

END

Final results (codepen):

<video id="stream" style="width: 100vw; height: 100vh;"/>

(async () => {
const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: {
      ideal: "environment"
    }
  },
  audio: false
});
const videoEl = document.querySelector("#stream");
videoEl.srcObject = stream;
await videoEl.play();

const barcodeDetector = new BarcodeDetector({formats: ['qr_code']});
window.setInterval(async () => {
  const barcodes = await barcodeDetector.detect(videoEl);
  if (barcodes.length <= 0) return;
  alert(barcodes.map(barcode => barcode.rawValue));
}, 1000)
})();

Happy coding!

I (roughly) defined (almost) every array method using recursion 😂

YCM Jason — Fri, 30 Apr 2021 12:07:51 +0000

So... I have decided to define every array methods using recursion. (I haven't really tested all of them... so there might be some errors.)

Also, I only defined the "essence" of most methods. Didn't follow the complete spec for most.

Why?

Why not?

How is this useful?

It is not.

`Array.from`

Array.from takes in two kinds of objects.

Array-like objects that have a length property with zero-indexed elements
Iterable objects that have an iterator at [Symbol.iterator]

const arrayFrom = (o) => {
  if ('length' in o) return arrayFromArrayLike(o)
  if (Symbol.iterator in o) return arrayFromIterator(o[Symbol.iterator]())
  return []
}

const arrayFromArrayLike = (arrayLikeObject) => {
  if (arrayLikeObject.length <= 0) return []
  return [
    ...arrayFromArrayLike({
      ...arrayLikeObject,
      length: arrayLikeObject.length - 1,
    }),
    arrayLikeObject[arrayLikeObject.length - 1],
  ]
}

const arrayFromIterator = (iterator) => {
  const { value, done } = iterator.next()
  if (done) return []
  return [value, ...arrayFromIterator(iterator)]
}

Note: we ignore the 2nd and 3rd arguments of Array.from. (see docs)

`Array.of`

const arrayOf = (...xs) => {
  if (xs.length <= 0) return []
  const [head, ...tail] = xs
  return [head, ...arrayOf(...tail)]
}

`Array.prototype.concat`

const concat = (xs, ...arrays) => {
  if (arrays.length <= 0) return xs
  const [ys, ...restArrays] = arrays
  if (ys.length <= 0) return concat(xs, ...restArrays)
  const [head, ...tail] = ys
  return concat([...xs, head], tail, ...restArrays)
}

Note: assuming concat only takes in 2 parameters

`Array.prototype.entries`

function* entries(xs, i = 0) {
  if (xs.length <= 0) return
  const [head, ...tail] = xs
  yield [i, head]
  yield* entries(tail, i + 1)
}

note: i does not exist in Array.prototype.entries

`Array.prototype.every`

const every = (xs, predicate) => {
  if (xs.length <= 0) return true
  const [head, ...tail] = xs
  return predicate(head) && every(tail, predicate)
}

`Array.prototype.fill`

const fill = (xs, k, start = 0, end = xs.length + 1) => {
  if (xs.length <= 0) return []
  const [head, ...tail] = xs
  if (start > 0) return [head, ...fill(tail, k, start - 1, end - 1)]
  return fillFromStart([head, ...tail], k, end)
}

const fillFromStart = (xs, k, end = xs.length + 1) => {
  if (xs.length <= 0) return []
  if (end <= 0) return xs
  const [_, ...tail] = xs
  return [k, ...fillFromStart(tail, k, end - 1)]
}

`Array.prototype.filter`

const filter = (xs, predicate) => {
  if (xs.length <= 0) return []
  const [head, ...tail] = xs
  return [
    ...(predicate(head) ? [head] : []),
    ...filter(tail, predicate)
  ]
}

`Array.prototype.find`

const find = (xs, predicate) => {
  if (xs.length <= 0) return undefined
  const [head, ...tail] = xs
  if (predicate(head)) return head
  return find(tail, predicate)
}

`Array.prototype.findIndex`

const findIndex - (xs, predicate) => {
  if (xs.length <= 0) return -1
  const [head, ...tail] = xs
  if (predicate(head)) return 0
  return findIndex(tail, predicate) + 1
}

`Array.prototype.forEach`

const forEach = (xs, fn) => {
  if (xs.length <= 0) return
  const [head, ...tail] = xs
  fn(head)
  forEach(tail, fn)
}

notes: ignoring index

`Array.prototype.includes`

const includes = (xs, predicate) => {
  if (xs.length <= 0) return false
  const [head, ...tail] = xs
  const predicate(head) || includes(tail, predicate)
}

`Array.prototype.indexOf`

const indexOf = (xs, x) => {
  if (xs.length <= 0) return -1
  const [head, ...tail] = xs
  if (head === x) return 0
  return indexOf(tail, x) + 1
}

`Array.prototype.join`

const join = (xs, separator = ',') => {
  if (xs.length <= 0) return ''
  const [head, ...tail] = xs
  return `${head}${separator}${join(tail, separator)}`
}

`Array.prototype.map`

const map = (xs, fn) => {
  if (xs.length <= 0) return []
  const [head, ...tail] = xs
  return [fn(head), ...map(tail, fn)]
}

`Array.prototype.reduce`

const reduce = (xs, fn, acc) => {
  if (xs.length <= 0) {
    if (typeof acc === 'undefined') {
      throw new TypeError('Reduce of empty array with no initial value')
    } else {
      return acc
    }
  }

  const [head, ...tail] = xs
  if (typeof acc === 'undefined') return reduce(tail, fn, head)
  return reduce(tail, fn, fn(acc, head))
}

`Array.prototype.reverse`

const reverse = (xs) => {
  if (xs.length <= 0) return []
  const [head, ...tail] = xs
  return [...reverse(xs), head]
}

`Array.prototype.slice`

Slice is a surprisingly annoying one to define. It needs to deal with negative indices, but you can't simply "mod" the numbers...

const slice = (xs, start = 0, end = xs.length) => {
  if (xs.length <= 0) return []
  if (start < 0) return slice(xs, Math.max(0, start + xs.length), end)
  if (end < 0) return slice(xs, start, Math.max(0, end + xs.length))
  const [head, ...tail] = xs

  if (end <= start) return []
  if (start > 0) return slice(tail, start - 1, end - 1)

  return [head, ...slice(tail, 0, end - 1)]
}

`Array.prototype.some`

const some = (xs, predicate) => {
  if (xs.length <= 0) return false
  const [head, ...tail] = xs
  return predicate(head) || some(tail, predicate)
}

Code Vlog: Building a Linktree Clone Static Site Generator

YCM Jason — Thu, 22 Apr 2021 22:17:06 +0000

Hey guys,

I have decided to make more coding videos on my youtube channel. This is my very first attempt at making a code vlog.

I hope you will enjoy the full video which will premieres on Saturday.

Full Vlog:

how not to use reduce

YCM Jason — Tue, 30 Jun 2020 10:33:13 +0000

Why not reduce?

This list intend to be a forever growing one that hope to collect typical patterns of reduce to avoid. Please feel free to suggest more examples!

This post is not about space / time performance perks by not using reduce. This is all about readability.

🔴 Do not

faces.reduce((acc, face) => {
  return [...acc, mask(face)]
}, [])

✅ Do

faces.map(mask)

🔴 Do not

bags.reduce((acc, bag) => {
  return [...acc, ...bag.apples]
}, [])

✅ Do

bags.flatMap(bag => bag.apples)

🔴 Do not

phones.reduce((acc, phone) => {
  return isNew(phone) ? [...acc, phone] : acc
}, [])

✅ Do

phones.filter(isNew)

🔴 Do not

dogs.reduce((acc, dog) => {
  return isHappy(dog) ? acc + 1 : acc
}, 0)

✅ Do

dogs.filter(isHappy).length

🔴 Do not

people.reduce((acc, person) => ({
  [person.dna]: person
}), {})

✅ Do

Object.fromEntries(
  people.map(person => [person.dna, person])
)

🔴 Do not

people.reduce((acc, person) => {
  return Math.max(acc, person.age)
}, -Infinity)

✅ Do

Math.max(...people.map(person => person.age))

Writing cleaner code with the rule of least power #ROLP

YCM Jason — Wed, 08 Apr 2020 23:28:56 +0000

The rule of least power suggests that:

the less powerful the [computer] language, the more you can do with the data stored in that language.

An example of this would be JSON vs Javascript object literal.

Javascript object literal is clearly more powerful:

It can have references to variables and native javascript objects, e.g. Set, Map, RegExp and even functions.
It has a more complex syntax, e.g. keys without ", keys with [] to refer to other variables etc.

In contrast, JSON is much less powerful:

It only supports strings, numbers, JSON object, arrays, boolean and null.
You can only define an entry with "property": ....

Although JSON is less powerful, it is much more straight-forward to parse and understand, both by humans and computers. This is one of the reasons why JSON has become the standard in data transfer nowadays.

I learnt about this rule a few years back; but have only recently realised it can also improve the quality of our code.

I would extend the rule of least power, so that it is not only applicable to choices amongst computer languages / systems, but also to choices amongst every line of code we write.

This article uses Javascript in the examples but the principle is applicable to other languages.

Abstract

When writing computer programs, one is often faced with a choice between multiple ways to express a condition, or to perform an operation, or to solve some problem. The "Rule of Least Power" (extended) suggests choosing the least powerful way suitable for a given purpose.

Expression Power and Readability

Readability of a piece of code has huge impact on maintainability, extensibility, optimisability etc. Readable code is much easier to be analysed, refactored and built on top of. This section explores the connection between the choice of expressions and the readability of a piece of code.

Principle: Powerful expression inhibits readability.

The power of an expression can also be thought of as "how much more it can do beyond achieving a specific purpose".

Consider the following example:

// More powerful: RegExp.prototype.test
/hi/.test(str)
// Less powerful: String.prototype.includes
str.includes('hi')

The first expression /hi/.test(str) is more powerful because you could do so much more with regex. str.includes('hi') is pretty much all String.prototype.includes can do.

The reason why str.includes('hi') is more readable is that it requires no extra thinking to understand it. You can be 100% sure that str.includes(...) will only check if ... is a substring of str. In the contrary, /.../.test(str) would require reading into ... in order to figure out what it actually does.

Consider another example:

// More powerful: Array.prototype.reduce
['a', 'b', 'c'].reduce((acc, key) => ({
  ...acc,
  [key]: null
}), {})
// Less powerful: Object.fromEntries + Array.prototype.map
Object.fromEntries(['a', 'b', 'c'].map(key => [key, null]))

The same arguments about power and readability apply similarly here. ['a', 'b', 'c'].reduce(...) can reduce to literally anything, whereas Object.fromEntries(...) will definitely return an object. Hence, Array.prototype.reduce is more powerful; and Object.fromEntries(...) is more readable.

More examples

// More powerful: RegExp.prototype.test
/^hi$/.test(str)
// Less powerful: ===
str === 'hi'

// More powerful: RegExp.prototype.test
/^hi/.test(str)
// Less powerful: String.prototype.startsWith
str.startsWith('hi')

// More powerful: RegExp.prototype.test
/hi$/.test(str)
// Less powerful: String.prototype.endsWith
str.endsWith('hi')


/// More powerful: Array.protype.reduce
xs.reduce((x, y) => x > y ? x : y, -Infinity)
// Less powerful: Math.max
Math.max(...xs)

// More powerful: Array.prototype.reduce
parts.reduce((acc, part) => ({ ...acc, ...part }), {})
// Less powerful: Object.assign
Object.assign({}, ...parts)


// More powerful: Object.assign - can mutate first object
Object.assign({}, a, b)
// Less powerful: Object spread
{ ...a, ...b }


// More powerful: function - have its own `this`
function f() { ... }
// Less powerful: arrow function
const f = () => {...}

// More powerful: without destructure - who knows what the function will
//                                      do with the universe
const f = (universe) => { ... }
// Less powerful - f only needs earth
const f = ({ earth }) => { ... }

"Depowering"

At this point, we have established and demonstrated how powerful expression can come with some readability tradeoffs. This section explores the possibility to reduce power of an expression in order to increase readability.

Depowering by conventions

The holy trinity of array methods .map, .filter and .reduce were borrowed from functional programming languages where side-effects are not possible.

The freedom, that Javascript and many other languages provide, has made the holy trinity more powerful than they should be. Since there is no limitation about side-effects, they are as powerful as a for or while loop when they shouldn't be.

const xs = []
const ys = []
for (let i = 0; i < 1000; i++) {
  xs.push(i)
  ys.unshift(i)
}

// we can also use map / filter / reduce
const xs = []
const ys = []
Array.from({ length: 1000 }).filter((_, i) => {
  xs.push(i)
  ys.unshift(i)
})

The above example demonstrates how the holy trinity are able to do what a for loop is capable of. This extra power, as argued in previous section, incurs readability tradeoffs. The reader would now need to worry about side-effects.

We can dumb down / "depower" .map, .filter and .reduce and make them more readable by reinforcing a "no side-effect" convention.

[1, 2, 3].map(f) // returns [f(1), f(2), f(3)] AND DO NOTHING ELSE
xs.filter(f) // returns a subset of xs where all the elements satisfy f AND DO NOTHING ELSE
xs.reduce(f) // reduce to something AND DO NOTHING ELSE

.reduce is the most powerful comparing the other two. In fact, you can define the other two with .reduce:

const map = (xs, fn) => xs.reduce((acc, x) => [...acc, fn(x)], [])
const filter = (xs, fn) => xs.reduce((acc, x) => fn(x) ? [...acc, x] : acc, [])

Due to this power, I personally like another convention to further depower .reduce. The convention is to always reduce to the type of the elements of the array.

For Example, an array of numbers should try to always reduce to a number.

xs.reduce((x, y) => x + y, 0) // ✅

people.reduce((p1, p2) => p1.age + p2.age, 0) // ❌

people
.map(({ age }) => age)
.reduce((x, y) => x + y, 0) // ✅

Depowering by abstractions

Abstractions are a good way to depower expressions. An abstraction could be a function, data structure or even types. The idea is to hide some power under the abstraction, exposing only what is needed for the specific purpose.

A great example would be the popular Path-to-RegExp library. This library hide the power of the almighty RegExp, exposing an API specific for path matching.

For example

pathToRegExp('/hello/:name')
// will be compiled to
/^\/hello\/(?:([^\/]+?))\/?$/i

Here is a more advanced example.

const y = !!x && f(x)
return !!y && g(y)

!!x && f(x) is common pattern to make sure x is truthy before calling f(x). The && operator can definitely do more than just that, as there is no restriction about what you can put on either side of &&.

A way to abstract this is the famous data structure: Maybe aka Option. Below is a super naive non-practical implementation:

// Maybe a = Just a | Nothing
const Maybe = x => !!x ? Just(x) : Nothing()

const Just = x => ({
  map: f => Maybe(f(x))
})

const Nothing = () => ({
  map: f => Nothing()
})

Yes! Maybe is a functor

With this abstraction, we can write the following instead:

return Maybe(x).map(f).map(g)

In this example, Maybe hides away the && it is doing internally, giving confidence to readers that f and g can be safely executed, or ignored depending on x and f(x).

If you are interested in learning more about data structures like this, take this course I found on egghead. It goes through fundamental functional programming concepts in a fun and engaging way! Totally recommend!

The last example is depowering via types. I will use typescript to demonstrate.

type Person = {
  name: string
  age: number
  height: number
  weight: number
}

// More powerful - is f going to do anything with the person?
const f = (person: Person) => { ... }
// Less powerful - f only needs the name. But will it mutate it?
const f = (person: Pick<Person, 'name'>) => { ... }
// Even less powerful - f only reads the name from the person
const f = (person: Readonly<NamedThing>) => { ... }

Pinch of salt

Please take the advice in this article with a pinch of salt.

This article highlights my formalisation about the relationship between the power of an expression and readability. And ways that we can depower expressions to increase readability.

There are still many factors contributes towards the readability of a piece of code besides the power of expressions. Do not blindly choose the less powerful expression. Do not "depower" every line of code into a function call. Do not put every variables into Maybe.

I am still in constant discovery and theorization on the topic of "good code". My mind might change over time. But ever since I introduced this idea to my team, we have not found a single instance where this rule fails. We even start using #ROLP (Rule Of Least Power) to reason about why one code is better than the other. So my faith is strong here, and is growing every day.

I hope the rule of least power (extended) can inspire you to produce better code in the future! Please experiment with it and let me know what you think!

DEV Community: YCM Jason

TypeScript Mutually Exclusive Unions: From `?: never` to `ExclusifyUnion`

Mutually Exclusive Unions in TypeScript (and why ExclusifyUnion rocks)

The basic problem

The ?: never trick

Scaling This Pattern

Introducing ExclusifyUnion

A familiar example: Zod’s safeParse

Key Takeaways

Introducing @ts-migrating: The Best Way To Upgrade Your TSConfig

😩 The Pain of Upgrading tsconfig

So what do people do?

🧠 A Better Way: @ts-migrating

🔌 How It Works

1. Language Service Plugin

2. CLI Tooling

Type check with the plugin

Annotate your errors

🧪 Real Example: noUncheckedIndexedAccess

✅ Why You Should Use It

🌟 Ready to Migrate?

7 Modern Use Cases of IIFE

⏳ What Is an IIFE? (And Why Was It Essential in the var Era?)

Use Case 1: Enable async/await

Use Case 2: const with switch

Use Case 3: Inline Guard Clauses

Use Case 4: Stateful Functions

Use Case 5: Object Property Initialisation

Use Case 6: Try-Catch IIFE

Use Case 7: Hierarchies of Abstraction

Final Thoughts

TRY {} CATCH {} ‒ FIXED! (with a surprisingly old trick)

The Problem with try-catch

The "Do Not Throw" Pattern

Enter IIFE: Immediately Invoked Function Expression

Looking Ahead: Do Expressions

Final Thoughts

[Boost]

I Recreated Tom Riddle’s Diary, But Used My Soul Instead 👻

YCM Jason ・ Feb 6

I Recreated Tom Riddle’s Diary, But Used My Soul Instead 👻

YCMJason's Diary 📖✨

Recognizing Handwriting ✍️

The Journey:

Running an LLM for Free 💸

The Journey:

Final Thoughts 🧠

Advanced Typescript: Typing Partially Applicable Functions

TL; DR

Recap: How to make functions partially applicable in JavaScript

Goal of this article

Typing the add Function

Typing 2-ary Functions

Typing N-ary Function

Implementing in TypeScript

Calling the Partially Applicable Function with No Arguments

Extended: Preserving argument names

Limitations

Conclusion

Detecting barcode from the browser!!!

Background

Article Synopsis

Part 1: Getting feed from camera

Part 2: Detect barcode from camera feed

END

I (roughly) defined (almost) every array method using recursion 😂

Why?

How is this useful?

Array.from

Array.of

Array.prototype.concat

Array.prototype.entries

Array.prototype.every

Array.prototype.fill

Array.prototype.filter

Array.prototype.find

Array.prototype.findIndex

Array.prototype.forEach

Array.prototype.includes

Array.prototype.indexOf

Mutually Exclusive Unions in TypeScript (and why `ExclusifyUnion` rocks)

The `?: never` trick

Introducing `ExclusifyUnion`

A familiar example: Zod’s `safeParse`

😩 The Pain of Upgrading `tsconfig`

🧠 A Better Way: `@ts-migrating`

🧪 Real Example: `noUncheckedIndexedAccess`

⏳ What Is an IIFE? (And Why Was It Essential in the `var` Era?)

Use Case 1: Enable `async/await`

Use Case 2: `const` with `switch`

Typing the `add` Function

`Array.from`

`Array.of`

`Array.prototype.concat`

`Array.prototype.entries`

`Array.prototype.every`

`Array.prototype.fill`

`Array.prototype.filter`

`Array.prototype.find`

`Array.prototype.findIndex`

`Array.prototype.forEach`

`Array.prototype.includes`

`Array.prototype.indexOf`

`Array.prototype.join`

`Array.prototype.map`

`Array.prototype.reduce`

`Array.prototype.reverse`

`Array.prototype.slice`

`Array.prototype.some`