A Note on Trouble-shooting UI issues — Addendum to Setting up Nested Routes in a Note-taking App (pt 3)

Last week I ended my post by mentioning that I had gotten the functionality/prop passing of my app mostly working in conjunction with routing via react-router, but still had some messy UI to clean up.

The following day, doing a morning standup/phone call with a friend and former classmate Tom Cantwell — frontend wiz — I mentioned another bug that was bothering me, and suggested we take a look at it. Whereupon, we dived into some pair programming.

I was noticing that sometimes when clicking the button to show an individual note, the button would either work or freeze up, and after clicking a few times it would work and show the individual note. I hypothesized that I might be passing props in some way that violated best practices, and that React was being forced to re-render a bunch of times in a highly suboptimal way that was making this basic operation slow down and take a while.

Tom on the other hand immediately began cornering the problem by surrounding the bug in ever tightening concentric circles of tests. I didn’t ask him if he formulated a hypothesis first about what was generating the bug. But from my own perspective he seemed fairly open-minded or agnostic about the source of the bug. He just started looking at the machinery. He didn’t express doubt or disapproval of my theory and conceptual hand-waving, but neither did he agree with it. We just got to work looking at the code.

Eventually we arrived at the NotePreviewCard component, the component rendering the actual button that is supposed to link to the NotePage’s parent Route component, causing the NotePage to display.

This is what it looked like:

If I pull out the code snippet (below), can you see the problem?

<Button variant=”secondary” >

<Link to={`${match.url}/${props.id+1}`} > 📖 </Link>

</Button>

The button was wrapping the link, when it should have been vice versa. This caused the clickable field to be very small, much smaller than the button itself, and just the size of the open book emoji held inside the button.

Cursor hovers over button but does not detect a link, since the button itself does not have a link to property:

When cursor hovers over open book emoji (which has a link to property), the link becomes visible in the bottom left corner of the screen:

The problem was a UI issue, not a functionality issue or highly technical issue relating to how React renders. We fixed it by simply changing the code to this:

<Link to={`${url}/${props.id+1}`} >

<Button variant=”secondary”>

<div>📖 </div>

</Button>{“ “}

</Link>

Tom mentioned that to avoid a problem like this, if he has an element with an onClick event listener, he often will add an onHover event listener to that element as well, and have the onHover trigger a visual change in the element, so that he can see exactly when the cursor is actually able to activate the onHover, and by extension, the onClick.

I wanted to share this because I think this is a really smart way of adding behavior to a webpage that not only improves UX (user experience) by showing that an element is ready to be clicked, but also DX (developer experience), by making behavioral testing more straightforward and intuitive.

Tom has an arts background and excels in visual work, so it makes sense that I would learn this from him. Thanks Tom!