Blag

Almost eleven years ago, I wrote a blog post titled "Query String Hell". A couple years later I wrote a query string parsing library. A lot has changed in the last eleven years, and since I was rebuilding my blog I felt it was time to revisit some of my older posts that have aged less like wine and more like milk.

At the time there weren't many good references, nor tools available for client-side query string parsing. Fortunately, browsers have since adopted the URL standard, and implemented the URLSearchParams class.

I saw a useBoolean utility hook the other day which looked something along the lines of:

const useBoolean = (defaultValue = false) => {
  const [value, setValue] = useState(defaultValue);

  const toggle = useCallback(() => {
    setValue((value) => !value);
  }, []);

  const on = useCallback(() => {
    setValue(true);
  }, []);

  const off = useCallback(() => {
    setValue(false);
  }, []);

  return [
    value,
    {
      toggle,
      on,
      off,
      setValue,
    },
  ];
};

It got me thinking about how simple terse I could make the implementation, so I decided to write things out to see what it might look like.

TypeScript supports decorators which are very convenient for adding complex functionality to classes in a declarative way.

Recently I was doing some work that involved media queries and it struck me that a decorator would be a particularly useful pattern for associating a media query with a class property. @media(...) even looks like a CSS media query.

I was recently looking into formatting numbers in JavaScript, and had to format a number with its ordinal suffix. That is, getting the "st" suffix for "1st", "nd" suffix for "2nd", etc. It seems like it would be easy enough to do, and because it seems so easy to do, there are many answers on Stack Overflow with many different attempts.

Most of them are variations of this logic (don't do this):

function ordinal(n) {
  switch (n % 100) {
    case 11:
    case 12:
    case 13:
      return "th";
  }
  switch (n % 10) {
    case 1:
      return "st";
    case 2:
      return "nd";
    case 3:
      return "rd";
    default:
      return "th";
  }
}

I was recently building some helper classes in TypeScript, and those classes could be called in a variety of ways.

Many functions have different signatures that are compatible, largely through optional parameters.

function example(foo: string, bar?: number, baz?: boolean) { ... }

For the helper classes I was writing, the different signatures weren't compatible, and required some branching logic in order to support the different scenarios.

Fortunately, TypeScript supports function overloading for cases where the argument types aren't necessarily compatible.

I fell down a brief rabbit hole this morning while attempting to refactor some TypeScript code.

I had some code along the lines of

if (this.foo.bar?.baz === 'example') {

that was repeated in a variety of locations.

I wanted to refactor it to

if (this.isExample) {

but one of the nuances of that refactor is that the first version includes an implicit type predicate for this.foo.bar to not be undefined, because this.foo.bar must be set for .baz to equal 'example'.