-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/plugin custom graphql scalars #47
base: master
Are you sure you want to change the base?
Feature/plugin custom graphql scalars #47
Conversation
- ensures this is a non-breaking change
- Initially had the whole plugin toggled.
@TimLehner 👍 BTW, have you seen #10 (comment)? 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://www.npmjs.com/package/graphql-iso-date for more info about the difference between Date
and DateTime
custom GraphQL scalars. 😉
const customISODateTypeHandler = { | ||
render: (arg, styleConfig, onChangeHandler) => ( | ||
<input | ||
type="date" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it should be "datetime-local"
instead of "date"
, because you use .toISOString()
.
}} | ||
/> | ||
), | ||
canProcess: (arg) => arg && arg.type && arg.type.name === 'Date', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it should be "DateTime" instead of "Date", because you use .toISOString().
import * as React from 'react'; | ||
|
||
function canProcess(arg) { | ||
return arg && arg.type && arg.type.name === 'Date'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it should be "DateTime" instead of "Date", because you use .toISOString().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The DateInput is distinct from the example in the README which demonstrates adding additional handlers not bundled with the explorer.
This bundled plugin is just a direct implementation of the Date input in the POC PR.
function render(arg, styleConfig, onChangeHandler) { | ||
return ( | ||
<input | ||
type="date" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it should be "datetime-local" instead of "date", because you use .toISOString().
@FluorescentHallucinogen |
- changes in editor now reflected in inputs
@sgrove @dwwoelfel Please review this pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 |
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. |
…into feature/plugin-custom-graphql-scalars
Have moved everything into The goal is to be able to provide the best of both worlds:
This 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