Объяснение различных реализаций функции разрешения в graphql

СЕРЬЕЗНЫЙ РАЗГОВОР: документы GraphQL.js не так хороши. На мой взгляд, они никогда не должны были использовать примеры с buildSchema, потому что это по понятным причинам приводит к такой путанице.

GraphQL.js (то есть пакет graphql) — это реализация GraphQL на JavaScript. Построение схемы в GraphQL.js выполняется программно путем создания экземпляра класса GraphQLSchema:

const userType = new GraphQLObjectType({
  name: 'User',
  fields: {
    id: {
      type: GraphQLID,
    },
    email: {
      type: GraphQLString,
    },
  },
});
const queryType = new GraphQLObjectType({
  name: 'Query',
  fields: {
    user: {
      type: userType,
      resolve: () => ({ id: 1, email: '[email protected]' }),
    },
  },
});
const schema = new GraphQLSchema({
  query: queryType,
})

Если мы напечатаем эту схему на языке определения схем (SDL), она будет выглядеть так:

type Query {
  user: User
}

type User {
  id: ID
  email: String
}

Работать с SDL гораздо проще, чем писать весь этот код. Однако GraphQL.js не позволяет создать полнофункциональную схему из SDL. Это делает предоставляет функцию buildSchema, но эта утилита создает схему без каких-либо резольверов (и ряд других функций, таких как разрешение типов объединения/интерфейса).

Пакет graphql-tools предоставляет функцию makeExecutableSchema, которая позволяет создавать схему из SDL и объекта карты преобразователя. Это то, что используется под капотом apollo-server и graphql-yoga. makeExecutableSchema создает схему из SDL, используя buildSchema, а затем мутирует полученный объект, добавляя распознаватели в постфактум.

В GraphQL.js функция resolve (или преобразователь) для поля принимает четыре параметра — родительское значение, аргументы поля, контекст и объект GraphQLResolveInfo. Если мы создаем GraphQLObjectType как userType в приведенном выше примере, это необязательная функция, которую мы можем предоставить для каждого из полей в нашем объекте. Это функция такой же, которую вы определяете, когда создаете карту преобразователя для использования с graphql-yoga. Это единственная реализация преобразователя полей.

Так что там с buildSchema??

Примеры в документах используют GraphQL преобразователь полей по умолчанию:

export const defaultFieldResolver: GraphQLFieldResolver<any, *> = function(
  source,
  args,
  contextValue,
  info,
) {
  if (typeof source === 'object' || typeof source === 'function') {
    const property = source[info.fieldName];
    if (typeof property === 'function') {
      return source[info.fieldName](args, contextValue, info);
    }
    return property;
  }
};

Как видите, логика разрешения по умолчанию ищет свойство с тем же именем, что и поле в исходном (родительском) значении. В нашем примере выше преобразователь user возвращает {id: 1, email: '[email protected]'} — это значение, которому соответствует поле решает. Поле имеет тип User. У нас нет определенного преобразователя для нашего поля id, поэтому преобразователь по умолчанию делает свое дело. Поле id преобразуется в 1, потому что это значение свойства с именем id в родительском объекте, которое получает распознаватель.

Однако родительское значение также может быть функцией, а не объектом. Если это функция, она вызывается первой, а затем используется возвращаемое значение. С чем вызывается функция? Ну, он не может передать ему родительское значение (из-за бесконечной рекурсии), но он могу передает ему оставшиеся три параметра (args, context и info). Вот что он делает.

Теперь о фокусе ??

В нашем примере я могу опустить преобразователь для поля user и вместо этого передать функцию корневому значению.

const root = {
  user: () => ({id: 1, email: '[email protected]'})
}

Корневой объект — это просто необязательный объект, который передается в качестве родительского значения преобразователям на корневом уровне (например, вашим типам Query или Mutation). В противном случае эти преобразователи не имели бы родительского значения.

Query — это операционный корневой тип — он служит «точкой входа» в остальную часть вашей схемы. Любым полям типа Query будет передан корневой объект в качестве родительского значения. Если я пропущу преобразователь для поля user, преобразователь по умолчанию 1) проверит родительский объект на наличие свойства с тем же именем, 2) найдет свойство и определит, что это функция, 3) вызовет функцию, 4) разрешит поле в возвращаемое значение функции.

ТАДА!

Однако, поскольку функция вызывается распознавателем по умолчанию и не используется как распознаватель, она получит только три вышеупомянутых параметра вместо 4.

Это удобный способ обойти невозможность фактически предоставить пользовательские преобразователи для схемы, но он очень ограничен. Он работает только для корневых типов, поэтому мы не можем предоставить поддельные преобразователи для полей User или других типов. Мы не можем использовать интерфейсы или объединения в нашей схеме, потому что мы не можем предоставить resolveType функции. И так далее...

Надеюсь, это внесет некоторую ясность. И, надеюсь, мы сможем обновить документы в ближайшем будущем, чтобы избежать всей этой путаницы.