Ze specyfikacji:
Typ obiektu GraphQL (ObjectTypeDefinition) ... nie nadaje się do ponownego wykorzystania [jako dane wejściowe], ponieważ typy obiektów mogą zawierać pola definiujące argumenty lub zawierać odniesienia do interfejsów i unii, z których żaden nie jest odpowiedni do użycia jako argument wejściowy . Z tego powodu obiekty wejściowe mają w systemie odrębny typ.
To jest „oficjalny powód”, ale istnieje kilka praktycznych powodów, dla których nie można użyć typu obiektu jako typu obiektu wejściowego lub użyć typu obiektu jako typu obiektu wejściowego:
Funkcjonalność
Zarówno typy obiektów, jak i typy obiektów wejściowych mają pola, jednak te pola mają różne właściwości, które odzwierciedlają sposób, w jaki te typy są używane przez schemat. Twój schemat może potencjalnie zdefiniować argumenty i jakąś funkcję przeliczającą dla pól typu obiektu, ale te właściwości nie mają sensu w kontekście wejściowym (tj. Nie możesz rozwiązać pola obiektu wejściowego - ma już jawną wartość) . Podobnie, wartości domyślne można podać tylko dla pól typu obiektu wejściowego, a nie dla pól typu obiektu.
Innymi słowy, może się to wydawać powielaniem:
type Student {
name: String
grade: Grade
}
input StudentInput {
name: String
grade: Grade
}
Jednak dodanie funkcji specyficznych dla typów obiektów lub typów obiektów wejściowych jasno pokazuje, że zachowują się one inaczej:
type Student {
name(preferred: Boolean): String
grade: Grade
}
input StudentInput {
name: String
grade: Grade = F
}
Wpisz ograniczenia systemowe
Typy w GraphQL są pogrupowane w typy wyjściowe i typy wejściowe .
Typy danych wyjściowych to typy, które mogą być zwracane jako część odpowiedzi wygenerowanej przez usługę GraphQL. Typy danych wejściowych to typy, które są prawidłowymi danymi wejściowymi dla argumentów pól lub dyrektyw.
Te dwie grupy nakładają się na siebie (tj. Skalary, wyliczenia, listy i wartości inne niż null). Jednak typy abstrakcyjne, takie jak związki i interfejsy, nie mają sensu w kontekście wejściowym i nie mogą być używane jako dane wejściowe. Oddzielenie typów obiektów i typów obiektów wejściowych pozwala upewnić się, że typ abstrakcyjny nigdy nie jest używany, gdy oczekiwany jest typ wejściowy.
Projekt schematu
Podczas reprezentowania encji w schemacie jest prawdopodobne, że niektóre encje rzeczywiście „współużytkują pola” między swoimi typami danych wejściowych i wyjściowych:
type Student {
firstName: String
lastName: String
grade: Grade
}
input StudentInput {
firstName: String
lastName: String
grade: Grade
}
Jednak typy obiektów mogą (iw rzeczywistości często to robią) modelować bardzo złożone struktury danych:
type Student {
fullName: String!
classes: [Class!]!
address: Address!
emergencyContact: Contact
# etc
}
O ile struktury te mogą przekładać się na odpowiednie dane wejściowe (tworzymy Studenta, więc przekazujemy również obiekt reprezentujący jego adres), często tak nie jest - tj. Może musimy określić zajęcia ucznia za pomocą ID klasy i ID sekcji, a nie obiekt. Podobnie, możemy mieć pola, które chcemy zwrócić, ale nie chcemy mutować, lub odwrotnie (jak passwordpole).
Co więcej, nawet w przypadku stosunkowo prostych jednostek często mamy różne wymagania dotyczące dopuszczalności wartości zerowej między typami obiektów i ich „odpowiednikami” obiektami wejściowymi. Często chcemy zagwarantować, że pole zostanie również zwrócone w odpowiedzi, ale nie chcemy, aby te same pola były wymagane w naszych danych wejściowych. Na przykład,
type Student {
firstName: String!
lastName: String!
}
input StudentInput {
firstName: String
lastName: String
}
Wreszcie, w wielu schematach często nie ma mapowania jeden do jednego między typem obiektu a typem obiektu wejściowego dla danej encji. Typowym wzorcem jest wykorzystanie oddzielnych typów obiektów wejściowych dla różnych operacji w celu dalszego dostrojenia walidacji danych wejściowych na poziomie schematu:
input CreateUserInput {
firstName: String!
lastName: String!
email: String!
password: String!
}
input UpdateUserInput {
email: String
password: String
}
Wszystkie te przykłady ilustrują ważną kwestię - chociaż typ obiektu wejściowego może czasami odzwierciedlać typ obiektu, znacznie mniej prawdopodobne jest, że zobaczysz go w schematach produkcyjnych ze względu na wymagania biznesowe.