I’m still getting used to Tailwind’s feature-set, but it’s quickly getting accepted into the category of knowledge I unoriginally call “evergreen skills”. I’m finding it builds very naturally off of CSS knowledge which made for a fast grok.

That said, I haven’t put much effort in UI design while working only with Tailwind before and I’m missing the conviction I have when using a component library. The careful, bespoke thought given to each component is fun and a great exercise, but wow it’s easy to start yakshaving.

I just needed a simple card element to display a title and image so I could move onto setting up project directory pages. I ended up with this:

I don’t think it’s bad; with a little more polish I think it could be kind of nice, though the polaroidiness doesn’t quite fit the vibe I’m hoping for so I’m going to iterate on it some more.

This sort of rabbithole leaves me with questions about the nature of designing from scratch, and when it’s worth digging deep into an interaction vs roughing out a complete user flow. Especially if I want to ship lots of little changes often.

I finally released the garage + project pages after weeks of on-and-off work, excitedly showing the deployed site to my partner (like I do every time something is barely presentable) only to find out that Safari on iOS smashes my header items together and doesn’t respect flexbox row-reverse 🙃.

I don’t have an iPhone so I guess I’m commandeering hers one of these days.

edit: nevermind, I just screwed up some styles

Just a quick update. I managed to pretty easily migrate from a hand-rolled content reading system to Astro Content Collections. My original folder structure and logic mapped almost perfectly to the new scheme so all I really needed to do was take satisfaction in deleting a few lines of regex and an extraneous config file.

The crux of the work boiled down to collating the two types of “project content” I have: project indices (a project’s “main body”), and entries (the numbered subsections).

This was mainly so I could avoid redefining project-level-metadata in every log entry like the project’s name and related image. It’s just a lazy implementation right now; they’re grouped by folder so I split Astro’s built-in content id key with "/" to rip out the common folder name and group with that.

What actually convinced me to do the migration was the Zod frontmatter validation. I expected more content types to pile up over time and managing all of them with typeguards sounded kind of nightmarish. Zod makes it easy. I’ve only fully adopted Zod recently but now that I’m looking it seems to be everywhere. Here’s to hoping this honeymoon phase fades into a healthy relationship.

Project content types are easy enough with Zod’s discriminatedUnion. I ended up discriminating an isIndex key on values true and undefined to mimic optionality. That way I can just omit isIndex in my project entry files.

I would’ve liked to allow an explicit isIndex === false, but unfortunately from what I can tell discriminatedUnion doesn’t support discriminating states where the key allows for more than one value, i.e. things like discriminator: z.literal(false).optional() won’t work without adding a duplicate schema entry for both z.literal(false) and z.undefined(). I’m sure there’s some performance reason for this (or I’m just missing something) but the mild inconvenience stuck out in what has been an otherwise very ergonomic library. It’s a minor gripe.

With this I’m calling the pathsweeping work for the garage page officially over, and that the (slightly procrastinated) writing part can proceed at full speed.