Open TimLehner opened 4 years ago
@TimLehner :+1: BTW, have you seen https://github.com/OneGraph/graphiql-explorer/issues/10#issuecomment-580644398? It would be really nice to have plug-ins for input fields that are object types with child fields, not only scalars (leafs). Is this possible with this PR?
Also found #31.
@FluorescentHallucinogen I have added support for more complex types, the plugins need to return some React.Element-like object. I've added an example implementation of a plugin for a Complex Number type in the README
@sgrove @dwwoelfel Please review this pull request.
I can, but I wonder if it would be better to provide that sort of functionality using typescript compiler options?
I could look at some tsconfig to make the output dist/ a single file? Feels better to me to generate that then force the code structure one way
@TimLehner can you move everything into the
Explorer.js
file. We're trying to keep a single file because some people copyExplorer.js
and drop it into their code base for development or because they want to make small customizations for their environment.
I don't mind dropping a folder in if it means the code is split up according to the classes used. It makes updating easier when we can preserve original code in files that don't need customization.
This is great!
@TimLehner can you move everything into the
Explorer.js
file.We're trying to keep a single file because some people copy
Explorer.js
and drop it into their code base for development or because they want to make small customizations for their environment.
Have moved everything into Explorer.js
as requested. I will look into making a new PR to split Explorer.js
up into the individual classes responsible, and typescript-ify my contributions.
The goal is to be able to provide the best of both worlds:
Explorer.js
file, still in ES2016 or similar, for users who wish to drag-and-drop this single file into their implementation and make small tweaksThis will be a separate PR, so I think this can now be closed and merged if there are no further comments -- would it be nice if the plugins are based on an abstract base class so it is clear for third-parties how to implement their own plugins?
@dwwoelfel PTAL.
@sgrove @dwwoelfel Ping.
This is an expansion of the ideas in PR #46