Вот там уже массив

Тут пример есть также

Советую сразу сделать глобальный обработчик на уровне линка. Удобнее

Не совсем понимаю, как мне в моем коде получить доступ к этому массиву?

Совсем не догоняю(

Всем привет )
Нужен ментор , минут 30-40  времени займёт,  чтобы объяснить пару вопросов по apollo. Никогда с graphql не взаимодействовала (знаю как реализовать логику на редакс,  а тут мозг поплыл как все правильно надо реализовывать. Проблема в том еще , что функциональные компоненты недопустимы).
Задача уровня джуна(только frontend).
Время это самая ценная штука и поэтому оно будет оплачено . Пишите в личку , если будет время и желание помочь)

Какая странная задача, функциональные компоненты не допустимы :)

Да , ужс , а не задача

привет) а как принято передавать ошибки, связанные с бизнес-логикой?

query Me {
        me {
            ... on User {
                name
                email
                projects {
                    name
                    display_name
                }
            }
            ... on OperationError {
                errors {
                    code
                    message
                }
            }
        }
    }

скажем, по какой-то причине при попытке запросить список проектов, произошла ошибка (скажем, у данного пользователя не может быть проектов), вы эту ошибку будете выводить на верхний уровень (сразу внутри data) или же внутри projects сделаете внутреннюю OperationError, слегка раздув запрос? или вообще как-нибудь по-другому (как именно)?

type Query {
    me: UserResponse!
}

type Error {
    code: Int!
    message: String!
}

type OperationError {
    errors: [Error!]!
}

type User {
    name: ID!
    email: String!
    projects: [Project!]!
}

type Project {
    name: ID!
    display_name: String!
}

union UserResponse = User | OperationError

скажем, вот пример схемы для данного примера запроса, считаете ли вы правильным сделать некий ProjectResponse = Project | OperationError в данном случае или поступить иначе?

ещё есть случаи, когда нужно вернуть статус, либо какой-то скаляр. Можно сделать тип CustomResponse и в нем опционально поля и для ошибок, и для status, и для data.

затем union UserResponse = User | CustomResponse

вообще, я статус операции по __typename проверял обычно, то есть по типу ответа

меня тут интересует вот эта вещь с вложенными ошибками

насколько хорошо и правильно внутри User в projects возвращать что-то кроме Project

вот еще вариант

export interface CustomErrorsInterface {
  errors: CustomError[]
}

@ObjectType()
export class CustomError {
  constructor({
    property,
    errorMessages,
  }: {
    property: string
    errorMessages: string[]
  }) {
    this.id = v4()
    this.property = property
    this.errorMessages = errorMessages
  }
  @Field(() => ID)
  id: string
  @Field(() => String)
  property: string
  @Field(() => [String])
  errorMessages: string[]
}

@ObjectType()
export class CustomErrorsResult implements CustomErrorsInterface {
  constructor({errors}: CustomErrorsInterface) {
    this.errors = errors
    this.id = v4()
  }

  @Field(() => ID)
  id: string

  @Field(() => [CustomError])
  errors: CustomError[]
}

по вашему мнению ошибки могут быть вложенными в правильный результат или же их надо выделять отдельно?

в случае запросов вида users { projects {name } }, ошибка по проекту должна быть на верхнем уровне или внутри пользователя?

если что, я использую Python/Ariadne, а не JS/TS на стороне сервера (на стороне клиента Apollo Client/Vue Apollo), но в данном случае это не важно, это детали реализации, а мне тут больше интересно узнать лучшие практики про схему/запросы)

Много мнений есть на этот счёт разных. В большинстве случаев решают ошибки сервера 5хх бросать исключением, а любые другие считать бизнес ошибками и отправлять их как результат, а не исключение