-
Notifications
You must be signed in to change notification settings - Fork 4
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
Why are Graphql Types converted into interfaces ? #103
Comments
So interfaces are used because the typescript docs recommend using them over type aliases whenever possible (primarily because they're extensible). Interfaces were chosen before graphql union/interfaces were actually implemented. The type aliases were used for interface/unions, because I found having the union type for all implementations extremely useful. Is there a downside to using interfaces that I'm unaware of? Perhaps we should look into alternatives for flow if there are |
Its not so much the interface, as the conflicting name and the lack of options (at least from what I found) around the union type. For my situation what would be nice:
|
Hey, so I took a stab at building a more "flow-esque" type generation format that matches the nomenclature that flow tends to use. This is the gist of it (using lodash, and node require instead of es modules). If there is interest, I'd be happy to open a PR with these changes to the packages/flow-language settings: const { camelCase, upperFirst } = require('lodash')
const pascalize = str => upperFirst(camelCase(str))
const { DEFAULT_OPTIONS: TS_OPTIONS } = require('@gql2ts/language-typescript')
const FLOW_WRAP_PARTIAL = partial => `$SHAPE<${partial}>`
const FLOW_INTERFACE_NAMER = name => `${pascalize(name)}`
const FLOW_INTERFACE_BUILDER = (name, body) => `export type ${name} = ${body}`
const FLOW_ENUM_NAME_GENERATOR = name => `${pascalize(name)}`
const FLOW_TYPE_PRINTER = (type, isNonNull) => (isNonNull ? type : `?${type}`)
const FLOW_POST_PROCESSOR = str => `/* @flow */
${str}
`
const FLOW_NAMESPACE_GENERATOR = (namespaceName, interfaces) => `
// graphql flow definitions
${interfaces}
`
const DEFAULT_OPTIONS = {
...TS_OPTIONS,
printType: FLOW_TYPE_PRINTER,
generateInterfaceName: FLOW_INTERFACE_NAMER,
generateEnumName: FLOW_ENUM_NAME_GENERATOR,
interfaceBuilder: FLOW_INTERFACE_BUILDER,
generateNamespace: FLOW_NAMESPACE_GENERATOR,
wrapPartial: FLOW_WRAP_PARTIAL,
postProcessor: FLOW_POST_PROCESSOR,
}
module.exports = DEFAULT_OPTIONS |
@arahansen looks good to me, a PR would definitely be welcome 😄 FWIW you can also use |
Here's a snippet from one of my flow exports
flowtypes.js
schema.graphql
I can sort of see why this decision was made - you wanted a concrete type with the name of the interface that is a union of all the types implementing that interface. So to get around that you moved all graphql types to be interfaces and only generate types for these unions. It seems unnecessary and its confusing to have different names between code types and graphql types.
The text was updated successfully, but these errors were encountered: