Modelling A Bad Request

Previously I said how I like to look for quick wins as it helps to keep the momentum going.

Another quick win is creating an object that describes the outcome of a bad request.

Here’s what we had in the proof of concept:

const badRequest = {
  status: -1,
  ok: false,
  redirected: false,
  headers: {},
};Code language: TypeScript (typescript)

I don’t see much reason to change this.

By the end of our first pass of the Fetcher implementation, we saw that we would likely convert Headers from a fetch response into a plain old JavaScript object.

The status of -1 should never naturally happen. It’s not a valid status HTTP response code. But it is still numeric. I guess we could come up with some different numbers to represent specific problems, but YAGNI, right?

So, in summary, our badRequest output gives us a status code we know cannot actually happen on a valid response.

It tells us that things were not ok.

It cannot possibly have redirected.

And we ended up with no headers.

All we actually need is a unit test, and this one is simple:

import { badRequest } from "./bad-request";

describe("bad request object", () => {
  test("should define a base bad request object", () => {
    expect(badRequest).toEqual({
      status: -1,
      ok: false,
      redirected: false,
      headers: {},
    });
  });
});Code language: TypeScript (typescript)

I like to call this out as its own concept. A unit test ensures we don’t inadvertently change this concept without realising it (because the test broke).

But yeah, we probably won’t write an easier bit of code or test in this little project.