Blag

When building apps with large complex datasets, a common problem while testing is that a component may interact with many parts of the application state.

When this happens, it's inconvenient to have to stub out the full application state in every test.

There are a variety of approaches to this problem, each with its own set of tradeoffs.

Using deep partial data with mock functions is one of my preferred ways to make testing easier.

As with any large system built by a many contributors over many years, the Web Platform has many small mistakes, inconsistencies, irritating behaviors, and missing features. In smaller scale systems these bits of technical debt accumulate over time and some are occasionally even fixed.

Unfortunately due to the requirement of backwards compatibility, many of the things that bother me about building on the web can never be fixed or changed.

This post is a place for me to vent list the changes I might make if I could.

The way to determine if you value something is by determining how much you're actually willing to pay for it.

In September of this year I had the unfortunately common experience of being laid off from my job.

Soon after I began the process of applying for new positions, which resulted in receiving many rejections from the companies I'd been applying to.

I'm used to the format of rejection emails, but being told you're "not quite the right fit" or that "other candidates are a stronger match" is never pleasant.

That is, until I received a rejection from Zapier. It was the kindest, most thoughtful rejection I've ever received in 17 years of being a software engineer. Even though it's still a templated response, it shows empathy that is lacking from most businesses these days.

Over many years of reading other people's code I've developed a system for how I conduct code reviews.

Many people have praised me on my code reviewing skills, I'd like to share my approach so that others may benefit from my experience.

That's not to say that my approach is perfect. While I've been using this approach for over a decade, I still make occasional changes when I find room for improvement.

Responsive horizontal navigation solutions can be challenging when different amounts of content might exceed the available horizontal space. Six to ten links might fit fine on a large screen device, but then overflow significantly on small screen devices.

This post covers one approach to solving the problem, where links that would overflow are automatically moved to a dropdown list.

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.