I noticed while revisiting this dusty marvel that the date being displayed was obscenely wrong. The month was two months off, the hours were several time zones away, and the date was always less than seven. And here I thought I had left it stable, at least worthy of v1.
All you need is 🧤
Doo doo dooda doo 🎺 time for some debugging. Thankfully I left myself some dev treats, like debug logging switches, and a clever cross-module emitter that reports its behavior dutifully. And after wrastling with some seriously strange output, I reached the taproot of the issue: the ECMAScript Date object or a rather rudimentary misunderstanding of said object.
Proper Cloning is the Key to Dating Mutations
You see, I don’t have a lot experience with dating mutations. If you would have asked me a year ago what I thought about mutating dates, I would have laughed in your face. Date mutants?! That’ll get messy on the quick.
But with a little spritz of immutability, I was able to hack through the underbrush, and escape from this barekly tolerable quagmire. And now look. I get to write about it too! Here’s what I learned. Hope it helps someone.
As it turns out, the crux was object mutation or immutability which was seemingly the word of the day. Earlier as I was brushing up on some React, and was reminded that this principle dictates some key aspects of React’s architecture. Isn’t it funny-not-funny how the Universe seems to contain only enough to keep us engaged, just enough novelty to keep us believing the world of forms and images is real?
set the Date object in any fashion, the mutation will show up everywhere that Date object is referenced.
To avoid this confusion, we can create new instances of the Date object like so:
// generate a new instance of the Date object const newDate = new Date(2020, 07, 31); // assign that object elsewhere, a reckless clone const anotherDate = newDate; // generate a responsible clone const anotherNewDate = new Date(newDate); // set a date newDate.setDate(22); // assess the impact console.log(newDate); // 2020-07-22 console.log(anotherDate); // 2020-07-22 console.log(anotherNewDate); // 2020-07-31
This conundrum is one React seeks to help us avoid. By preferring and enforcing strict, deep immutability, (as scary as that sounds) of data objects, React allows us to jump forward and back among states of the application as though time has more than one-dimension and moves in more than one-direction. And, I mean, it does, obviously.
To fix the Passage Clock, I had to give up dating mutations and embrace immutability for our Date objects. I now create a few instances of the Date object, and the awkwardness is all but gone, and the old clock is humming along like a hummingbird in a humvee with Humphrey Bogart.
Thanks for showing up. Showing up is key.
Oh dear, look at the time…