Clojurians Log v2

I was just thinking about the case where a nested component (e.g. TodoItem) needs details about two different things (e.g. movies and user), in that case qlkit/get-query seems insufficient. I can see two solutions to this: * Named queries, this seems to be how relay works. Fragments are named, and can be placed as appropriate by the owner. This means that query would return a map. * Creating a unified model elsewhere which unites Movies & Users into a single model, which is then moving you into denormalization territory, which isn't something I personally enjoy working with. Am I missing an obvious feature in Qlkit for this?

@dominicm The concept is that the structure of the queries mirrors the structure of the UI- Think of the queries as a direct embodiment of the UI. If a component needs information in a denormalized fashion then the queries will request data in a denormalized fashion. The goal is to make the components "as dumb as possible"... all the "smarts" are in the parsers that have to fulfill the queries and do the work of transforming the data- The structure of the data retrieved by the queries will therefore very much be "denormalized"- The goal is that there is an organized process for taking transactions that happen in this denormalized context and resolving the correct, normalized action in the data source, again with parsers. Following this, rerenders will be triggered that propagate the changes from the normalized data source back to the UI.

@dominicm I think what you're trying to do is to perform the denormalization in the component code (i.e pulling in Movies and Users) which you can do (to a degree) in other graph query systems, but qlkit is opinionated in saying that "components should be dumb, smart parsers need to spoon-feed data to components."

@dominicm I definitely think others will have these kinds of questions and I'd love to build an example app that gives guidance on this- Can you outline what scenarios such an example app should cover to be helpful?

This makes total sense, this is really great. My example was somewhat contrived from saying to a colleague "oh, but there's no reason it has to be coupled to the hierarchy of your graph, you can do... oh, yeah, that doesn't work :thinking_face:"

This does mean I now have to figure out a more complex way of unifying these things in order to talk to my normalized backend, :thinking_face: Especially as I'm trying to avoid using qlkit on the backend, as we're talking to a GraphQL API.

@dominicm I also looking for a om-like(graph) frontend that has integration with graphql

I think that qlkit's query language is compatible, with some massaging of course.

There are two more example apps now, both are still getting some polish before ending up in the docs but are already useful for reference: - An example of routing & tabbing with heterogenous tabs https://github.com/forward-blockchain/qlkit-routing-example - A mastermind game: https://github.com/forward-blockchain/qlkit-mastermind-demo