The debugger example looks in the same vein as Reveal, Membrane, Portal and other dev runtime ui tooling. But I guess in a more classical sense apps have been rendering their admins screens forever. Still, looks magical to me, bridging over that threshold.
I was thinking of you advocacy of not wanting a data access query language for ui when I had to write this monstrosity today
{{#each gql.data.site.product.variants.edges}}
{{#with node}}
{{#eq isPurchasable false}}
{{#with options}}
{{#each edges}}
<h1 style="font-size: 20px;" class="variant-gql text-xl h-8 border text-red-500">
{{#with node}}
Name: {{displayName}}
{{#with values}}
{{#each edges}}
{{#with node}}
id: {{entityId}}
label: {{label}}
{{/with}}
{{/each}}
{{/with}}
{{/with}}
</h1>
{{/each}}
{{/with}}
{{/eq}}
{{/with}}
{{/each}}
Destructuring data from a graphql api in handlebars html.Someone needs CLJS macrology! 🙂
You know, we talked about "premature lock-in to plausible but bad solutions". When I heard about graphql I immediately imagined something wonderful. Then I checked it out. Hmmm.
Tilton's Law: "If your improvement turns out to require more code than without it, git reset --hard."
re the "debugger", I had no idea what to in the second matrix that I was going to inject into the static HTML, tho of course to stress the system we needed reactive flow between them, including especially state coming and going as the user worked. Mirroring one matrix with another was actually trivial code-wise. More fun would be displaying the state DAG, but I do not want to get distracted from the MX training exercise. But that could be a great exercise for Matrix 201. And I can chalk up some diagnostic tooling at the same time. Even better building the diagnostic tooling will also be an intro to MX internals, killing yet another bird. Hmmm....