RelativeTVList: A Better Way to Work with Large Related TV Datasets

This post followed the earlier discussion about very large TV option lists and pointed to a more practical answer: RelativeTVList. Instead of trying to cram a huge dataset into a static TV definition, the idea was to reference or resolve values relative to a better source.

Why this mattered

• large option lists become hard to maintain manually
• editor UX degrades quickly when one field carries too much unrelated data
• structured references are usually easier to update than giant inline value maps

The original note also mentioned compatibility with DocLister output, which makes sense. Once the TV becomes a relational bridge rather than a plain list, the frontend needs predictable ways to render those referenced values.

Main takeaway

When a TV starts behaving like a small database, it is time to treat the problem as a data-structure problem. RelativeTVList was one attempt to do exactly that.

Source: original community announcement.