Plugin: lifecycle hook to enable prettifying queries on load
rybon opened this issue · 10 comments
Would it possible to auto prettify (opt-in, off by default) GraphGL calls when opening them in a GraphiQL window? I know there's a button in the UI to do this, but I would prefer to have this done as soon as a GraphQL URL is opened, so the extra button click is not needed. Perhaps this can be configured by setting an options object on the graphiql field? So instead of graphiql: true one could set graphiql: { autoPrettify: true } when for example setting up a express-graphql server.
@benjie how would this be a potential plugin? seems too simple for a potential plugin
Plugins should be able to augment GraphiQL in many ways; one such way is to hook lifecycle events. This same hook could be used in multiple ways, for example to tell the query to run every second via setInterval, or to bind the editor to something else in the application (e.g. a visual block editor, or GraphiQL Explorer, or something else). Similarly they should be able to augment the options object for GraphiQL to add their own options so users of the plugin can configure it via the standard GraphiQL configuration interface.
This is part of my vision for plugins, anyway. I need to set aside some time to write up how I think it can work (and what I think it should be able to do) some time in the next few weeks.
One of the great things about plugins is that they enables features like this that are only needed by a small subset of the GraphiQL users to be maintained outside of core, and yet still have deep integration. This keeps core lean, whilst reducing the need to fork the project, and makes it more powerful for its users.
I like the idea of plugins, but this particular feature seems too trivial for a plugin and is already present in the code base (under the Prettify button).
Here's the express-graphql side of this feature: graphql/express-graphql#507
Sure, the code may be simple, but the more options we have out of the box the harder it is for new users to understand, and the more of a maintenance burden we have on keeping the documentation and code up to date, the more places for bugs to hide, and the greater the number of combinations of options that we need to test (e.g. how well do query and autoPrettify work together?).
By handling features like this via a plugin, you can get something that you can use immediately (without having to maintain your own fork) and share with others, and GraphiQL itself can remain a very lean core that only deals with the concerns of the majority of its users.
I understand your concerns regarding feature creep and keeping the API surface area and associated permutations limited, but how would one build a plugin for this feature? The method that is invoked is located inside the GraphiQL component. How would a plugin invoke it?
Do we really have to draw a line in the sand for this particular feature? I would understand it a bit better if this was a complicated implementation, but given that the PR only contains 5 LOC (excluding whitespace) and is really straightforward, why start this discussion now?
ok, i'm beginning to see what you guys mean for a plugin system for 1.0 for sure
for the purposes of 0.x, which will be the active version for the next 8 months at least, possibly this will be enough? i imagine 1.0 will probably need a ground-up rebuild