Хотя я считаю себя средним разработчиком JavaScript, я неделями пытался понять фундаментальные концепции, которые очевидны для тех, кто живет в экосистеме React.js. Итак, это список вещей, которые я сейчас вижу, которые я считаю недостаточно хорошо документированными или объясненными для людей вроде меня - тех, кому нравятся идеи, лежащие в основе GraphQL, и которые хотят его использовать, но не обязательно имеют какой-либо опыт работы с React. js набор инструментов.

Список будет соответствовать стилю Дэйва Седдиа, который сделал временную шкалу для изучения React. Это было действительно удобно, когда я экспериментировал с React несколько месяцев назад, потому что он четко и логично разделяет темы, сглаживая кривую обучения для новичков. (По крайней мере, это сгладило мою)

0. Введение

Прежде всего, вы должны иметь представление о том, что такое GraphQL, а что нет.

Получите мотивацию:

Получите основные понятия:

Для меня есть несколько причин тратить время на изучение GraphQL, даже если я не разработчик React, а энтузиаст API:

  • Меньше обращений к серверу
  • Заявляй, что хочешь, получай именно то, что тебе нужно
  • Самоанализ - это удобно и полезно
  • GraphiQL IDE потрясающая
  • Создание прокси-серверов на основе существующих REST API

GraphQL - это спецификация, не зависящая от языка, но самой популярной из них является JavaScript. Итак, для понимания официальной документации полезно знать JavaScript. (Подробнее об этом позже)

1. Языки

Во-первых, вы должны хорошо владеть хотя бы одним языком программирования и концепциями, лежащими в основе языка запросов GraphQL. Независимо от того, какой язык вы выберете, вы должны быть в порядке с двумя языками.

2. Синтаксис

Предполагая, что вы следуете официальному пути изучения GraphQL, вы получите некоторое представление о синтаксисе GraphQL. Вы можете улучшить свои навыки, пройдя онлайн-курс в качестве дополнительного. К концу этих двух вы почувствуете силу запроса информации декларативным способом, который является таким же особенным, как написание декларативных компонентов в React.

Затем, если вы будете следовать дорожке graphql.js на официальном веб-сайте, как это сделал я, вам придется привыкнуть к следующему:

  • Синтаксис JavaScript
  • ES6 синтаксис
  • Flow синтаксис

Большинство разработчиков наверняка обойдут ES6, но часть Flow была для меня действительно проблематичной. Почему? Потому что естественно перейти непосредственно к разделу типы, поскольку вы уже знаете, что все идет вокруг типов, но синтаксис - это то, что вы раньше не видели. (У меня не было)

Итак, через некоторое время вы, скорее всего, перейдете к высокоуровневому сценарию использования graphql.js с экспрессом, читая о GraphQLObjectType. В документации очень кратко описаны типы, а также что есть что, что есть где и т. Д. Не имея представления о том, что она написана в синтаксисе Flow (с ES6), вы о многом будете гадать.

Первым моментом, который приоткрывает глаза на различие синтаксиса, может быть то, что вы можете создавать типы несколькими способами. Вторая причина может заключаться в том, что контекст, поля и преобразователи начинают говорить с вами. Одно дело следовать руководствам и достигать результатов, имитирующих пример кода, но совсем другое дело, когда вы можете прочитать документацию и увидеть, что вы можете работать с обещаниями, глобальными переменными и как работать с полями в циклических зависимостях.

На момент написания статьи в официальной документации на сайте нет ни одного упоминания о Flow.

3. Разрешить ()

Если вы пришли из React, resolve(), возможно, вызовет ассоциацию с render(). Он служит совершенно другой цели, поскольку в основном отвечает на вопрос о том, какое поле следует рассматривать как часть данного типа, но для меня оно имеет такую ​​же простоту и важность. декларативному характеру.

Опять же, документация хороша тем, что дает простое объяснение того, что с ними можно делать, однако мне потребовалось некоторое время, чтобы расшифровать следующее:

fields: GraphQLFieldConfigMapThunk | GraphQLFieldConfigMap;

Было непросто понять, что GraphQLFieldConfigMapThunk используется, когда поля должны иметь возможность обрабатывать циклические зависимости.

Честно говоря, мне также потребовалось больше времени, чтобы понять, какие магические параметры входят в эту функцию. В разных руководствах используются разные способы получения необходимых аргументов, например, использование _ для первого аргумента (чтобы пропустить его использование) или использование деструктивного присваивания для получения части контекста и т. Д. Опять же, понимание документации с Flow помогает больше. чем console.log(...args), который я использовал, чтобы понять их.

«4. Реле"

Relay - это инструмент, который слабо связан с GraphQL. Он понадобится вам для более сложных сценариев, когда вам нужно кеширование, разбиение на страницы и т.д. необходимо в более крупных проектах или особых клиентских сценариях.

Не требуется изучать GraphQL.

5. Аполлон

Я слежу за ней даже больше, чем за эстафетой (из-за ЦРТ), но до сих пор у меня не было причин использовать ее. Со стороны он кажется блестящим и хорошо подкрепленным. Я думаю, что это направление следует использовать при использовании инструментария, отличного от React, и когда вам нужны более сложные решения с уровнем качества и крутости на уровне ЦРТ :)

Также не требуется изучать GraphQL.

Выводы

Я думаю, что разработчики React.js сейчас лучше понимают и работают с GraphQL. Это нормально, поскольку мало-помалу я начинаю видеть, как различные инструменты работают вместе для решения проблем определенными способами, которые естественным образом возникают благодаря пониманию концепций, лежащих в основе декларативного мышления в продуктах facebook на данный момент.

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

Думайте о подходе, ориентированном на клиента. Клиент как ваш потребитель API и клиент, который хочет что-то сделать. Должна быть причина, по которой документация GraphQL не упоминает напрямую взаимосвязанные и более сложные инструменты - вы используете их, когда они вам нужны.

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