DEV Community: hesxenon

how to (correctly) check if properties are optional

hesxenon — Sun, 04 Feb 2024 10:47:20 +0000

TL;DR

type IsKeyOptional<T extends Record<string | number | symbol, unknown>, Keys extends keyof T> = 
    {[Key in Keys]?: T[Key]} extends Pick<T, Keys> ? true : false;

type Foo = {
    foo?: string
    bar: string | undefined // this is not the same as foo!
}

type IsFooOptional = IsKeyOptional<Foo, "foo"> // true
type IsBarOptional = IsKeyOptional<Foo, "bar"> // false

The problem

Recently I've run into a problem with using zod where zod deliberatly adds | undefined to the value of a key to then add the optional flag ? depending on whether or not the value includes undefined.

This check isn't accurate though as there is a fundamental difference between optional keys and nullable values, which is the exact reason why exactOptionalPropertyTypes exists. "IF you give me a banana, I expect it to be a banana, not a banana | undefined"

Correct checking

Think of objects as rows of [key, value] tuples for a second and the solution becomes clearer. In order to determine whether a key is optional we have to check whether the respective row is present, not whether the value includes undefined. And with that in mind we can just say

for a set of keys construct rows that are optional and check whether those rows are equal to the rows for the same keys from the type we want to check against

Or, more picturesque:

isOptional	check	control
false	maybe the row exists	the row DOES exist (even if its value can be undefined)
true	maybe the row exists	maybe the row exists

Testing web components

hesxenon — Tue, 16 Jan 2024 15:56:38 +0000

The problem

Recently one of my pet projects - a web component that mimics, localized and extends the default <input> tag - had gotten complex enough that I couldn't warrant manual testing for it anymore. So, naturally, I tried to setup a unit testing environment. JSDom supports custom elements, right? Well yeah, kinda. Problem is, my little component wants to integrate with ElementInternals so plays nicely with forms. And JSDom hasn't implemented that at the time of writing. And with that I opted for puppeteer.

So if you find yourself reading this article at a point in time where JSDom has implemented ElementInternals I'd suggest to stop reading and try it with JSDom instead.

The basics

In a nutshell, all we have to do is startup a new page with puppeteer, fill it with some skeleton that includes our library and then add our web component to the body of that page, after which we can query for that element and assert it behaves and looks like we expect it to.

The requirements

Since I don't exactly like writing html strings by hand and jsx is such a nice templating language, I've used another library of mine to transform typed jsx into html strings.

So with a quick

npm install -D tsx-to-html puppeteer

we should have everything we need

The setup

A simple function to return us a page with our content should be enough.

// Utils/Test.tsx
import puppeteer from "puppeteer";
import { toHtml } from "tsx-to-html";
import * as Fs from "node:fs";

const lib = Fs.readFileSync("dist/index.js", "utf8");

const browser = await puppeteer.launch({ headless: "new" });

export const init = async (content: JSX.Element) => {
  const consoleMessages = [] as ConsoleMessage[];
  const page = Object.assign(await browser.newPage(), {
    console: { messages: consoleMessages },
  });

  page.on("console", async (msg) => {
    consoleMessages.push(msg);
    const args = await Promise.all(msg.args().map((a) => a.jsonValue()));
    console.log(...args);
  });

  page.on("pageerror", console.error);

  await page.setContent(
    toHtml(
      <html>
        <head>
          <script type="module">{lib}</script>
          <style>{css}</style>
        </head>
        <body>{content}</body>
      </html>,
    ),
  );

  return page;
};

All we're doing here is launch a new headless chrome, create a page in it, include our (preloaded) script (type="module" is necessary for me because I'm outputting ESM) and include the passed content in its body.

The tests

import { describe, it, expect } from "yourFavoriteTestrunner";
import { init } from "Utils/Test";

describe("uwc-input", () => {
  it("should have class pristine", async () => {
    const page = await init(<uwc-input></uwc-input>);
    const classes = await page.$eval("uwc-input", (input) =>
      Array.from(input.classList),
    );
    expect(classes).toContain("pristine");
  });
});

The importance of types

Don't forget to include your custom element in the HTMLElementTagNameMap for some nice type safety like this

class MyElem extends HTMLElement {}

declare global {
  type MyElem = (typeof MyElem)["prototype"];
  interface HTMLElementTagNameMap {
    "my-elem": MyElem
  }
}

The conclusion

Initially pushing this setup away from me for fear of being too complicated I think it took me longer to write this blog post than to get started with this, so... start testing, will ya?

the (not so big) Bang!

hesxenon — Wed, 01 Nov 2023 14:12:06 +0000

Premise

So I've just read this article here in which the author basically throws typescripts warning regarding potentially undefined values into the wind with the bang operator.

In short this allows you to do something like this:

const maybeElement = document.getElementById("foo");
maybeElement!.addEventListener(...); // <-- notice the ! before the .

So with this we can tell typescript to ignore the problems of accessing a property on a potentially null value.

My initial thoughts on this were "yeah, and if you'd use that in my codebase without a comment we'd have a stern talk" and while I stand by that - at least put a comment there on why you're sure it's not nullish - there is something to be said in favor of telling typescript to shut up; especially in a case like hers.

The Problem

So lets assume we don't want to do this and we just use the elvis operator (?.) instead -> maybeElement?.addEventListener. Great, now our code doesn't crash when the element isn't defined.

But think again... in such a scenario, what would be easier to trace? If the id of the element changes, maybeElement becomes null and with the bang operator it crashes "loudly" a few lines below.

If we just mindlessly change the ! into a ? it doesn't crash - but the event listener also isn't added which in turn means that we probably have a far more intricate and difficult to track bug on our hands. Maybe that bug even isn't discovered for a day or two and then what? Are you confident enough that you'll find the mistake within the same amount of time and effort as when the ! was still there?

The solution

Be mindful about your operators. It's not like ?. has no drawbacks and failing early is typically better. If you want to express "I need this to be non nullish" using ! could be acceptable - of course the best solution here would be to take a step back and think about what to do in case the element isn't found, which is why typescript warns you in the first place.

Conclusion

no such thing as mindless programming
?. can easily be abused to delay surfacing of errors
using ! probably means you should think harder about proper errors. Maybe an either/result monad as encapsulated by various libraries like fp-ts and effect?