The only thing I want to be really careful of is that this doesn't lead to a breakdown in the ~1:1 relationship between components and fragments. Eg: SidebarSolidDefinition uses SIDEBAR_SOLID_DEFINITION_FRAGMENT and broadly speaking, other components should define their own fragments that are scoped to their data needs, not re-use that one. We have some places where we are re-using fragments (I am definitely guilty of the GanttChart family of components all sharing a single fragment), but by and large it's a lot easier to keep the graphql queries accurate after refactors, etc. if it's 1:1. It'd be a real bummer if a year from now half the app was sharing RUN_TABLE_RUN_FRAGMENT :-p. Shouldn't be a problem, but we might have to watch out if the team grows and these are nice easy imports!

Yeah, agree that we need to keep an eye on this. I think it becomes harder once we have lower-level components with their own fragment definitions, that then get reused in larger fragments or queries because the consuming components render that lower-level component further down the tree. It's still technically 1:1, but it can end up looking like the fragment is being used in a lot of places as it gets further away from its paired component...which could encourage people to reuse fragments incorrectly in lots of places. :(

I wonder if there are any good tools for tracking this kind of thing.