From 3733b1e57cb7ea8432420a17b3660c69187e0a09 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Lytek?= Date: Sun, 14 Mar 2021 20:34:49 +0100 Subject: [PATCH] docs(fields): add info about renaming fields with a warning for inputs --- docs/types-and-fields.md | 13 +++++++++++++ .../version-1.0.0/types-and-fields.md | 13 +++++++++++++ 2 files changed, 26 insertions(+) diff --git a/docs/types-and-fields.md b/docs/types-and-fields.md index 7b84b4b9f..1cf2502d0 100644 --- a/docs/types-and-fields.md +++ b/docs/types-and-fields.md @@ -123,3 +123,16 @@ Also the `user` property doesn't have a `@Field()` decorator - this way we can h Note that if a field of an object type is purely calculable (e.g. `averageRating` from `ratings` array) and we don't want to pollute the class signature, we can omit it and just implement the field resolver (described in [resolvers doc](resolvers.md)). Be aware that **defining constructors is strictly forbidden** and we shouldn't use them there, as TypeGraphQL creates instances of object type classes under the hood by itself. + +In some case we may want to expose our classes or properties under a different types or fields name. +To accomplish this, we can use the `name` parameter or `name` property of decorator's options, e.g.: + +```typescript +@ObjectType("ExternalTypeName") +class InternalClassName { + @Field({ name: "externalFieldName" }) + internalPropertyName: string; +} +``` + +However, be aware that renaming fields works only for output types like object type or interface type. It's due to a fact that input fields has no resolvers that could translate one field value into another property value. diff --git a/website/versioned_docs/version-1.0.0/types-and-fields.md b/website/versioned_docs/version-1.0.0/types-and-fields.md index 9cdc48663..ae9d21a95 100644 --- a/website/versioned_docs/version-1.0.0/types-and-fields.md +++ b/website/versioned_docs/version-1.0.0/types-and-fields.md @@ -125,3 +125,16 @@ Also the `user` property doesn't have a `@Field()` decorator - this way we can h Note that if a field of an object type is purely calculable (e.g. `averageRating` from `ratings` array) and we don't want to pollute the class signature, we can omit it and just implement the field resolver (described in [resolvers doc](resolvers.md)). Be aware that **defining constructors is strictly forbidden** and we shouldn't use them there, as TypeGraphQL creates instances of object type classes under the hood by itself. + +In some case we may want to expose our classes or properties under a different types or fields name. +To accomplish this, we can use the `name` parameter or `name` property of decorator's options, e.g.: + +```typescript +@ObjectType("ExternalTypeName") +class InternalClassName { + @Field({ name: "externalFieldName" }) + internalPropertyName: string; +} +``` + +However, be aware that renaming fields works only for output types like object type or interface type. It's due to a fact that input fields has no resolvers that could translate one field value into another property value.