Vertical Collection: Ember.js and Lazy Loading

What happens when you load a list of over one thousand data points, each with their own specific boolean checks and data storage, on an Ember.js webpage? Similar to React Router, Ember uses a route and model system that involves loading the model for a particular page, making the API calls where necessary, processing the returned data, and displaying that to the user. In an attempt to improve performance, a frontend engineer (from a different team) decided to use Vertical Collection, an Ember addon designed for optimizing list loading. The philosophy of this addon is admirable, and I think it is the correct approach to rendering large amounts of data.

[Vertical Collection] focuses on improving initial and re-render performance in high-stress situations by providing a component for performant lists and svelte renders to match a core belief: Don't render the universe, render the scene.

Objectively, Vertical Collection is a great addition to a page that needs highly performant lists. However, as you'll soon see, this was not how it played out in our codebase.

As part of my login overhaul project, the product manager and UI/UX lead wanted to disable editing for view-only logins. Normally, logins that can be edited have a three-dot ellipses that opens a dropdown menu with the options "Edit" or "Delete". In old versions of the page, view-only logins could be "edited", but the Edit Login page would have a warning notification, and the Save button would be disabled. Adding the desired functionality was pretty straightforward: I sent an extra boolean down from the API endpoint, specifying whether a login was view-only or not. If a login was view-only, then I replaced the ellipses with the info icon, and disabled navigation to the Edit Login page.

When Vertical Collection was added, the entire page broke. Functionally, it stayed the same; view-only logins could not be be edited. Visually, we started getting a bug where both the info icon and the ellipses were being shown to the customer. Clicking on the ellipses didn't have any effect (no dropdown menu would appear), and for some reason, clicking on the ellipses would revert all double-icons to their normal appearance.

This was going to be difficult.

The biggest problem with debugging this code was that all of our code worked. Every boolean was processed correctly, every displayed value was correct. But for some reason, we had two icons rendering when we should've only had one. I built the code again and again, putting breakpoints at every possible location where it could make a difference. And every build, every debugging session, the booleans were correctly processed, and we still had the double-icon bug.

Eventually, I turned to the Vertical Collection Github repo, scouring the issues for something similar. I ended up finding something similar to my bug. It wasn't exactly the same, but it was close enough to begin working on a solution.

I wrote up my solution in the issue I found, so I won't repeat too much of what I said there. Essentially, I found a fix that involved hard-coding a login's editable state into the template. While this worked, it was pretty ugly code, and I sought the advice of my team during a live code review to figure out a better solution. Together, we found another place to add a separate update call. Everytime we rendered a login, we would check for an update to this boolean value, and reset our icon visibilities. This worked perfectly for our purposes, and fixed the issue.

While I'm glad this ticket has a happy ending, it does include a good warning for developers, and a good argument for the importance of code ownership. If I had not been clear that I was the owner and primary developer for the logins webpage, I think we'd be in a very different situation. Someone from outside my team changed the template without consulting me first; fortunately, my company's quality engineering team found the issue and reported it directly to me. I was able to fix the problem before it was pushed to production.

But there's a warning here, too. If you're modifying someone else's customer-facing code, double-check what the code's functionality should be. And, if you're writing customer-facing code, make sure you are noted as the code owner of those files. You never know what errors can get pushed without you noticing.