explore.opensauced.pizza VS Telescope

Following up on my post last week about the first aspect of a PR contribution to explore.opensauced.pizza, I'm going to talk about the second aspect of that PR - joyfully implemented as an HTML element (I really like these). So as I mentioned in the post before: We also wanted to let users quickly reproduce the queries we use in Open Sauced... this way, when its time to iterate on an existing feature, there's very little friction to finding that starting point. About a week before this, I had been working on a PR for tabulating the GraphQL API calls in the Open Sauced docs, so a lot of the details about API calls were pretty fresh. Side note, if you want line breaks inside a table in markdown, you'll need to use a element, but don't forget to use a self closing tag in the event your markdown file is parsed and used by a tool like Docusaurus, :cough, cough:. Shout out to @0vortex for cleaning up my messes! Anywho, after looking around at GraphiQL implementations, I came to the belief that most define a fetcher with the correct API endpoint/headers and otherwise things just work out of the box. Once the introspection query is run and the schema parsed and validated, the combination of the Explorer pane and the Query Editor pane make it really easy to build up and run valid queries. There's also a common pattern of using a default query so when the client first loads up, the query is pre-populated. What these two don't help with is reproducing and working with multiple queries. The approach I wound up taking was to store all of the dynamic queries in an object, and then generate a element in the toolbar, which updates the query contents and query name with the onchange event. Here's the piece of code that does the job...

Flow state is a rare treat for me these days. The last time I can remember being in that zone was working on a GraphiQL implementation for Open Sauced, https://explore.opensauced.pizza. The Open Sauced project makes use of OneGraph, to handle authentication and persisted query features in working with the GitHub GraphQL API. This was the first I had worked on any kind of GraphiQL implementation, so for those of you at the point I was at then, GraphiQL is an Open Source project that can be used to interact with a GraphQL API in an ad-hoc and dynamic way, allowing a developer to iterate quickly on features from a data retrieval standpoint. This post is about the PR #2 in the repo.

This app is itself is a Next.js app that relies on Vulcan.js, a full-stack JavaScript framework that I originally created for Meteor, and that Eric Burel later ported to Next.js. But we will likely phase out the Vulcan.js part eventually to make it a more standard codebase.

This app is itself based on a full-stack JavaScript framework I created, Vulcan.js. It works well enough for now, but in the future the app might need to be refactored in order to handle more surveys in parallel.