Dev Log: April 20 Wrap-up

Overview

Today was one of those days where small, brittle assumptions in the code finally caught up with us. Nothing flashy, just some honest debugging and making our data handling a bit more robust so things don't break the next time someone changes a sort order.

What I Worked On

Ironing out the print flow

I spent some time troubleshooting the document viewer. There was a nagging issue where the print action wasn't triggering correctly. It turned out to be a bit of a mismatch between the UI component and the print service. We were passing down a dynamic action type that didn't always align with what the handler expected. I decided to explicitly set the action to print when we're in that specific context. It’s a simple fix, but it ensures that the service knows exactly what to do with the file response without guessing. It feels much more reliable now.

Making templates less brittle

The bigger chunk of my afternoon was spent wrestling with some report templates. We had some logic for displaying 'amended' or 'finalized' notes that was honestly a bit too optimistic. It was hardcoded to look at the very first item in a list, assuming that's where the relevant data would always be.

Well, as soon as the data order changed—specifically when headers started appearing at the top of the list—the whole thing stopped showing the notes because index zero was no longer what we expected. I went in and scrapped the index-based logic for a filter-first approach. Now, the template actually searches the data for the specific remarks it needs. It's a bit more work for the engine, but it means we won't be back here fixing this the next time a backend dev decides to change the result sorting.

Wrapping Up

It wasn't a day of building massive new features, but it felt good to shore up some of these weak spots. It’s a reminder that [0] is often a dangerous thing to write in a template. Tomorrow, I'm hoping to dive back into some of the heavier logic on the reporting engine. Catch you then.