I'm still confused about generic components, and how their data ends up in tables. I think it would be clear if I understood: what would it take to turn the Todo app into a generic component?

Because as I understand it now, more complex generic components must be wrapped in a component that provides it with state

Anything that has an Ident will work as a completely relocatable thing, since all of the mutations related to it will target a table, and the query for it can be composed into a parent. The only thing it takes to move a component is to make sure you have a clear story around the server obtained data lifecycle

for example, if I load a todo list from the server, then as long as that load is relative to the todo list's ident, it won't matter where it goes in the UI...the data load is also relative

but if I have a global load that loads a bunch of todo lists, then I'll need to manage the data lifecycle of specific todo lists in the app (e.g. I'll have to write post-mutations that "heal" the database graph edges of the components to point to their data)

It is still an "independent component" inasmuch as a component that talks to servers can be

but if the data model moves to something larger, shared, and more global, then there is more work to do, as one would expect

@urbank ^^^

Hello all been lurking here a bit, @tony.kay thanks for all your transparency and work on the untangled project. We are having an issue with non-homogenous union queries that include one recursive component and multiple non-recursive components. Essentially the om/full-query composite-component returns only the information in regards to the recursive component and not the other unioned components. Has anyone solved this? Is it an expected outcome?

@tony.kay Thanks!