After my short encounter with it, I wouldn't say so. I wasn't aware of how well-protected we all were by those battle-tested date libraries. It's such an easy way to shoot yourself in the foot using plain Date objects. This example alone is enough to make you rethink some things:

new Date('2024-01-01')

What do you think this does? The date format is OK. The date should be parsed and we should get a Date object with the specified date set internally, right? Well, correct to some extent, but it depends on the time zone...

What if I told you that you could end up with a 2023-12-31 when converting that object to a string? If you don't know about Date quirks it's almost a certainty you will end up with this bug eventually.

What if I told you that you could end up with two different dates for these 2 inputs to the Date constructor:

• 2024-01-01

• 2024-01-01T00:00:00

This is the reality in which we as web devs live. It's not commonly known behavior unless you worked with something that required a deeper knowledge of the Date internals. This is something that caused a bug in my code the other day. It was reported by users that are behind the UTC. Now, why would that be the case?

It happens because Date assumes the time zone differently based on having time specified vs. the case with no time specified. And by assuming an input in the wrong time zone it ends up with the wrong date being set internally(shifted by a difference in a client's time zone offset to the UTC).

Look at this example, where I'm running the JS on the client located in the UTC+1 zone:

Do you notice any difference? :)

It's weird, it's unexpected, it's unintuitive. But, does it have some meaningful background, maybe some well-defined standard to back it up? Also no. This is a remnant of the old JS world, an error in specification that does not adhere to the ISO 8601 standard and never will because of backward compatibility issues.

new Date('2024-01-01') should do the same as new Date('2024-01-01T00:00:00') but it doesn't. Without time explicitly being set, it assumes that the input parameter('2024-01-01') is in UTC. Now if that code runs on the client that's behind UTC, for example, a western part of the globe. If the client's time zone lags for e.g. 6 hours, the Date constructor will produce a new Date object with the date/time being set to 2023-12-31T18:00:00. On the other hand, if you pass in the 2024-01-01T00:00:00 string(notice that one also doesn't specify a time zone) it won't assume UTC but rather use your local time zone offset and you will get the date object with the exact date/time for your time zone :).

This is where the bugs come from. Date constructor assumes UTC time zone for one input format while on the other hand, it uses the local time zone for the format that has time specified. Pretty unexpected. If you try to do the same inputs using moment.js you will get the expected and consistent behavior because date libraries handle so many weird cases for us out of the box.

It was a bit hard to dig out the exact reason why it behaves like this, but I eventually found the reason on MDN page:

Also, see the mentioned post on the topic and the proposal for a solution — proposed Temporal API. But at the moment this is the situation with Temporal API:

Leaving us with plenty of reasons to still choose to work with external libraries for dates. Just like the following couple of reasons:

// 1. Months are zero-indexed, while days and years are one-indexed
const date = new Date(2022, 0, 1); // January 1, 2022

// 2. Two-digit years are interpreted as 1900-1999
const y2k = new Date(99, 0, 1); // January 1, 1999

// 3. Negative years are allowed, representing years B.C.
const ancient = new Date(-44, 2, 15); // March 15, 45 B.C.

// 4. Parsing date strings can be inconsistent across browsers and locales
const parsedDate = new Date('03/15/2022'); // May not work consistently

// 5. Daylight Saving Time can cause unexpected behavior
const dst = new Date(2021, 2, 14, 2, 30); // March 14, 2021, 03:30 (skipped hour)

By the way, please consider a bit more modern options for handling dates like Day.js or date-fns. I mentioned moment.js just because it was the easiest to reach and verify the behavior, but other than that its usage is no longer recommended.

It's a bit tricky to cover this with tests and to make sure that the function triggers correctly for all the proper cases, ensuring it won't break with future changes. To make things even more serious this logic makes decisions for a critical user path during the app onboarding and could potentially break the app for new users.

Therefore tests should cover all the possibilities and lock the correct behaviour to make it future-proof. There are 2^7 = 128 flag combinations. Writing this by hand would be extremely time-consuming and error-prone. I decided to generate all the possible flag combinations in a 2D array matrix, iterate over rows and use row values to initialize flags. The test simply needs to go over all 128 rows and test for correct output based on all the input combinations.

First I needed to create a function that generates a 2D matrix with all the possible boolean combinations:

  function generateFlagCombinations() {
    const flags = [];
    const numFlags = 7;

    // Generate all possible combinations of boolean values for the flags
    // [[false, false, false, false, false, false, false], [true, false, false, false, false, false, false], ...
    for (let i = 0; i < Math.pow(2, numFlags); i++) {
      const flagCombination = [];
      for (let j = 0; j < numFlags; j++) {
        flagCombination.push(Boolean(i & (1 << j)));
      }
      flags.push(flagCombination);
    }

    return flags;
  }

For the actual test to simplify naming and focus on what's important, I'll just call the boolean flags A – G:

it('should activate in correct cases', () => {
  const flagCombinations = generateFlagCombinations();

  for (const [A,B,C,D,E,F,G] of flagCombinations) {
    const result = shouldShowProceedButton({A,B,D,E,C,F,G});

    if (E) {
      expect(result).toBe(A && !F);
    } else if (!G) {
      expect(result).toBe(false);
    } else {
      expect(result).toBe(A && (!C || (B && D && C)) && !F);
    }
  }
});

And that would be it. We've created:
- a small function that generates all the possible flag combinations — 128 rows representing 128 possible flag permutations
- a simple test that uses the generated combinations. It iterates over all the rows of a 2D matrix and uses the values to initialize the flags to test for every single possible combination

This way we can be sure that we've covered all the possibilities and that we know what to expect from a given function for every combination. This locks the function's behaviour in a way and makes it harder to accidentally change the behaviour.

By the way, I know that using so many flags to make a decision might not be the greatest strategy but sometimes you don't have other choice than to use what's already there 😶‍🌫️

Following is a minimal proof of concept that you can extend upon to provide better UX and save or process the file, add error handling etc. The example is intentionally bare bones and not using any libraries to get down to the gist of things. It sets up a minimal example that accepts and reads a file.

HTML side

<input type="file" />
<script>
    document
      .querySelector('input[type="file"]')
      .addEventListener('change', function(event) {
          const file = event.target.files[0];
          const formData = new FormData();
          formData.append('file', file);
          fetch(
            '/api/upload-route',
            { method: 'POST', body: formData }
          );
      })
</script>

This creates a raw HTML input field with "onchange" event handler attached to it. When a file is selected, it automatically appends its content to FormData object as a file field and makes a POST request using it for the body of the request. By using FormData, we produce a multipart/form-data encoded POST request. Simply put, we are sending a specific type of message to the server that can have multiple parts(i.e. text fields, files, etc.) and they are separated by a specified boundary.

Next.js app route handler side

const readFile = (req: Request): Promise<string> =>
  new Promise(async (resolve, reject) => {
    const data = await req.formData();
    const file = data.get('file') as File | null;

    if (!file) {
      return reject('No file sent!');
    }

    const buffer = Buffer.from(await file.arrayBuffer());
    const content = buffer.toString('utf8');

    resolve(content);
  });

export async function POST(req: Request) {
  const content = await readFile(req);
  const responseBody = JSON.stringify({ content })
  return new Response(responseBody);
}

On the Next.js side, we reverse the process. We call req.formData() to get the FormData sent from the client side. Read a specific field named file by using data.get('file') and then load the binary file content into a new Buffer and decode the content as a utf8 string.
POST handler function just uses decoded file contents to loop them back to the client inside a response to this API call.

This example assumes you have a textual file being uploaded and you need to access its contents inside an API route handler function. In case the file is binary, you'd probably want to skip the "read" part and just save or transition the contents to some other place.

Thank you for reading and Godspeed!

<button type="button">text</button>

Historically, the primary purpose for buttons was submitting and resetting HTML forms. “submit” was always the default type since button elements were used mostly for that purpose, submitting forms.

And we used them like so:

<form action="/send" method="post">
    <input placeholder="Enter your message" />
    <button>Save</button>
</form>

Then as JS evolved and became more and more powerful, people started building dynamic interfaces and apps. HTML buttons needed to follow and mimic the behaviour we see in native apps. There was a new requirement to have them trigger various actions inside the app, even more so than submitting forms. But, at the same time web platform has always been backwards compatible. For that reason, changing the existing HTML element to default to type="button" was not an option.

type="button" was introduced to support "new" behaviour that avoids the default of submitting forms.