You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Overhaul inflection so that it deals with BakedString vs RawString. BakedString.append(...) etc. Prevent thing being cooked twice - no biscuits.
One of these options:
/** * TypeScript hack: use this for inflectors that shouldn't be further * inflected - i.e. they can be used as field, argument, type, etc names */exporttypeCookedString=string&{$$cooked: undefined};classBakedStringextendsString{append(text: BakedString|string){returnnewBakedString(String(this)+text);}}
If we use BakedString then we can store properties onto it and give it methods for approved modification. One property can track where it came from (i.e. which inflector, and maybe even which version of the inflector e.g. if it came from a plugin). We could even trace all the RawStrings that were fed into that inflector and add those to the trace too, building a mermaid chart of how a particular string was derived. We'd need to then convert the BakedString back to a string in graphile-build before using it for a type name/field name/argument/etc - but this would also give us an opportunity to perform assertName and tell the user exactly where their error is coming from - we can also forbid field/arg names that haven't gone through inflection, encouraging the builtin inflector for lazy devs. (We could even trace that a particular field has come through a specific makeExtendSchemaPlugin, for example.)
Then we should make it so that camelCase/etc are never used directly - perhaps give them a __ prefix, they should only be used by inflectors like field(), type(), argument() which are used in non-prefixed inflectors. Inflectors that return RawString should have a _ prefix.
/** Every GraphQL type should go through this inflector */type(this: GraphileBuild.Inflection,rawName: string): CookedString{returnthis.upperCamelCase(rawName)asCookedString;},/** Every GraphQL field (object, and interfaces) should go through this inflector */field(this: GraphileBuild.Inflection,fieldNameRaw: string): CookedString{returnthis.camelCase(fieldNameRaw)asCookedString;},/** Every GraphQL input field (input objects) should go through this inflector */inputField(this: GraphileBuild.Inflection,fieldNameRaw: string,): CookedString{returnthis.field(fieldNameRaw);},/** Every GraphQL argument should go through this inflector */argument(this: GraphileBuild.Inflection,fieldNameRaw: string): CookedString{returnthis.inputField(fieldNameRaw);},
The text was updated successfully, but these errors were encountered:
Overhaul inflection so that it deals with BakedString vs RawString. BakedString.append(...) etc. Prevent thing being cooked twice - no biscuits.
One of these options:
If we use BakedString then we can store properties onto it and give it methods for approved modification. One property can track where it came from (i.e. which inflector, and maybe even which version of the inflector e.g. if it came from a plugin). We could even trace all the RawStrings that were fed into that inflector and add those to the trace too, building a mermaid chart of how a particular string was derived. We'd need to then convert the BakedString back to a
string
ingraphile-build
before using it for a type name/field name/argument/etc - but this would also give us an opportunity to performassertName
and tell the user exactly where their error is coming from - we can also forbid field/arg names that haven't gone through inflection, encouraging thebuiltin
inflector for lazy devs. (We could even trace that a particular field has come through a specific makeExtendSchemaPlugin, for example.)Then we should make it so that
camelCase
/etc are never used directly - perhaps give them a__
prefix, they should only be used by inflectors likefield()
,type()
,argument()
which are used in non-prefixed inflectors. Inflectors that return RawString should have a_
prefix.The text was updated successfully, but these errors were encountered: