Lists Inside Lists

Part 7 of 11: Lists Inside Lists

---

Every list I love starts small and then grows a second personality. My Field Recording Kit was fine until the cables took over. Suddenly a third of the rows were adapters and patch cables and the one weird right-angle connector I bought for a reason I no longer remember, and the list I built to see my gear was mostly about wires.

The fix isn't a longer list. It's a smaller one, split off and kept in its place. That's nesting.

Give a list a parent

When you create or edit a list, there's a Parent List field. Set it, and this list becomes a child of that one. I made a "Cables & Adapters" list and parented it under "Field Recording Kit." Now the kit stays about the big pieces (recorders, mics, bags) and the wire situation has its own home that I only open when I'm actually chasing a cable.

The relationship shows up everywhere the moment you set it. On the list itself, the header tells you its children:

A list detail page header showing the breadcrumb and a "Child lists: Cables & Adapters" label

And in the Tree View you get the outline: parents on the left that expand into their children, so you navigate the structure instead of scrolling a flat wall of lists.

The Tree View with the lists outline on the left showing the nested structure, and a selected list's rows on the right

It's a tree, not a tangle

A few things I appreciated once I started nesting in earnest. A list can have children and also be someone's child, so you can go more than one level deep when the shape calls for it. The app also stops you from creating a loop, so you can't accidentally make a list its own ancestor and tie the whole thing in a knot. That guardrail sounds obvious until you realize how easy it'd be to do by hand.

Nesting is strictly organizational. A child list is its own real list with its own schema and rows. Parenting doesn't merge them or force them to share columns. It just says "this belongs under that," which is exactly the amount of structure I want and no more.

Nesting versus connecting

There's a second kind of relationship worth naming so you don't confuse the two. Nesting is a parent-and-child hierarchy. Connections are a looser link between two lists that are related but not one-inside-the-other, and they show up as the solid colored edges in the Entity Diagram from the last post. Nesting is the folder; a connection is the piece of string between two folders. Most days you'll want nesting. The connection is there for when the relationship is real but the hierarchy isn't.

Break the monster into parts. Keep the parts in view. That's the whole trick, and it's the reason a list can grow with you instead of collapsing under its own weight.

Next I want to get out of the design chair and into the passenger seat: living in a list day to day, which is really about rows.

Adron