At the moment, reloading the page is the only way to reload changes to the schema/documentation of said schema.
It is fine in production, since schema will not change every second, and mostly fine in development (of a GraphQL endpoint) because the state is mostly kept.
However, the documentation resets, which means I either have to click the correct sequence of types, or use the search field, every time I refresh the page.
I think it would be very intuitive to reload the documentation as it was before refreshing the page. This could be done via a ?documentation=... query string (in addition of ?query=...). Any thoughts? :)
@astorije yeah this was one of the long outstanding improvements the doc explorer needs to be updated with. I think a url param is a good approach, but we should probably also bake this into the local storage, since there's a "state" object in the doc explorer and sometimes it's tedious to express the state in the url params. What do you think?
@wincent @AGS- cc
That makes sense. Is that how the query itself is stored, query string + local storage? If so then yeah, I think they should be stored the same way.
I think a good litmus test for whether something belongs in the URL is the answer to the question:
Is this the kind of thing I'd like to share a "deep link" to with another person?
If the answer is "yes", then it makes sense for it to live in the URL. The query param evidently satisfies that criterion, and the ability to deep-link to documentation as well seems pretty interesting too. Having said that, the URLs can already be pretty monstrous, so we may also want to consider other solutions to that particular deep-linking use case (for example, a link icon you can click to get the link as opposed to automatically updating the location bar like we do with queries).
Either way, storing it in local storage sounds fine too, I would think.
To link docs from other sources, it'd be nice to at least have it opt-in.. so it would support taking it from the URL, if not putting it back in.
What's the status on this?
We've just formed the GraphiQL Working Group, and this is one of the things that came up in the first meeting (I'm particularly interested in it as we already have a hack we've been using for a couple years in PostGraphile, though that only applies to hot-reload, not full page reload). This is definitely on the radar, but we cannot commit to a time-frame.
I've changed the title of this to make it more obvious to the maintainers on scan; but I think that the "on schema reload" part should be baked in, it's the "on page reload" that should be a plugin IMO.
Most helpful comment
We've just formed the GraphiQL Working Group, and this is one of the things that came up in the first meeting (I'm particularly interested in it as we already have a hack we've been using for a couple years in PostGraphile, though that only applies to hot-reload, not full page reload). This is definitely on the radar, but we cannot commit to a time-frame.