Что такое gatsby js
Когда Gatsby заменит WordPress: интервью с Михаилом Новиковым
Gatsby — не просто генератор статических сайтов. Это амбициозный проект, создатели которого замахнулись на долю WordPress на рынке CMS. Вокруг Gatsby сейчас шум и хайп в блогосфере и соцсетях, поэтому мы решили не отставать. Пообщались с Михаилом Новиковым, Staff Software Engineer, Core Team Gatsby.
Дмитрий Дементий: Михаил, добрый день. Расскажите, пожалуйста, о себе: кто вы, чем занимаетесь?
Михаил Новиков: Приветствую читателей. Меня зовут Михаил Новиков, работаю в Gatsby. Развиваю здесь opensource-проекты, занимаюсь GraphQL. Живу в Хельсинки, организовываю конференции React Finland и GraphQL Finland. Управлял стартапом Reindex, но сейчас сконцентрировался на работе в Gatsby.
Михаил Новиков, Staff Software Engineer, Core Team Gatsby
Д.Д.: Расскажите, пожалуйста, о Gatsby в двух словах.
М.Н.: Gatsby — фреймворк, написанный на React. Это генератор статических сайтов, с помощью которого можно создавать полноценные веб-приложения.
Gatsby выделяется очень высокой скоростью загрузки страниц. Фреймворк использует предварительную загрузку: когда пользователь открывает главную страницу, браузер в фоновом режиме подгружает данные, необходимые для отрисовки других страниц сайта, на которые есть ссылки с главной.
Сайт на Gatsby представляет собой React-приложение, поэтому загружаются только данные о разнице между страницами, а не страница целиком. При переходе обновляется виртуальный DOM, посетитель наслаждается высокой скоростью загрузки. Протестировать Gatsby можно на демо-сайте.
Д.Д.: Gatsby — генератор статических сайтов, написанный на React. Зачем понадобился ещё один генератор, если есть Jekyll, Hugo и другие неплохие инструменты?
М.Н.: Во-первых, до Gatsby не было генератора сайтов на React. Сейчас Gatsby пользуется популярностью в React-сообществе, этот генератор активно используют фронтенд-разработчики.
Во-вторых, Gatsby создаёт полноценные приложения. Все сайты, созданные с помощью Gatsby, поддерживают функциональность PWA из коробки. То есть владельцу сайта ничего не надо делать — его ресурс уже является прогрессивным веб-приложением со всеми преимуществами этой технологии. Также Gatsby поддерживает эффективную подгрузку страниц и картинок и другие функции, которые улучшают perfomance сайта.
Д.Д.: Gatsby сейчас активно развивается, вижу вокруг него информационную активность и даже хайп. В чём особенность этого инструмента?
М.Н.: Да, действительно, сейчас многие разработчики и представители CMS хотят работать с Gatsby. Поэтому вокруг инструмента началась информационная активность.
Наверное, главная особенность Gatsby — высокая скорость загрузки страниц. Это привлекает разработчиков и рядовых пользователей. Более того, высокая скорость доступна из коробки, то есть разработчикам не нужно делать лишнюю работу, как-то ускорять сайты.
Ещё одна особенность — Gatsby с помощью готовых плагинов умеет собирать данные из разных источников. Это могут быть CMS или файловые системы. Благодаря GraphQL Gatsby может одновременно работать с несколькими источниками, и это не влияет на perfomance сайта.
Д.Д.: Gatsby поддерживает PWA «из коробки». То есть созданный с помощью Gatsby сайт по умолчанию является прогрессивным веб-приложением. Можете рассказать об этом? Какие преимущества получают владельцы сайтов и посетители благодаря PWA?
М.Н.: PWA или прогрессивные приложения в первую очередь интересны благодаря офлайн-режиму. То есть сайты, поддерживающие функциональность PWA, работают даже без подключения к интернету. Это может быть важным для проектов, у которых мобильная аудитория. Например, путешественники в самолётах могут потреблять контент без подключения к сети.
Также PWA умеют устанавливаться на мобильные девайсы: смартфоны и планшеты. Это повышает вовлечённость аудитории, то есть даёт дополнительные преимущества владельцам сайтов. По функциональности PWA пока уступают нативным приложениям, но эту технологию активно продвигает Google.
Д.Д.: Gatsby работает с GraphQL. Расскажите пожалуйста, какие преимущества это обеспечивает?
М.Н.: GraphQL обеспечивает интерфейс для получения данных из разных источников. Благодаря этому Gatsby удобно использовать с разными источниками данных, в том числе с так называемыми headless CMS. То есть работать с контентом можно в Contentful или в том же WordPress, а рендеринг обеспечивает Gatsby.
Д.Д.: Gatsby — проект с открытым исходным кодом. Это бизнес-проект или всё-таки некоммерческий проект? Если бизнес-проект, то можете рассказать о бизнес-модели?
М.Н.: Да, ядро Gatsby — opensource-проект, так будет всегда. Gatsby Inc — коммерческая организация. Мы предоставляем сервисы для тех, кто использует Gatsby. Например, Gatsby Preview — инструмент для контент-менеджеров.
Д.Д.: Читал, что Кайл Мэтьюз, основатель Gatsby, однажды назвал Gatsby убийцей WordPress. Это серьёзное заявление или шутка? Gatsby правда хочет «откусить» долю рынка у WordPress и стать топовым инструментом для создания сайтов? На WP работает треть сайтов в интернете и две третьих сайтов на CMS.
М.Н.: Конечно, пока это скорее шутка. Но у команды Gatsby действительно серьёзные амбиции, и мы хотим стать популярными. Ставим высокие цели, и если получится стать такими же популярными, как WordPress, будем рады.
Д.Д.: WordPress одновременно простой и функциональный. Чтобы разобраться с ним, не нужны какие-то специальные знания и сверхспособности. В то же время это универсальный движок, на котором можно сделать всё — от личного блога до корпоративного сайта или интернет-магазина.
Gatsby всё-таки не для всех. Не каждый рядовой пользователь захочет устанавливать Node.js, разбираться с Markdown’ом. Не все понимают, что это за surge.sh и GitHub Pages, на которых можно задеплоить сайт на Gatsby за 1 минуту. То есть чтобы Gatsby серьёзно претендовал на долю рынка WP, ему надо стать таким же простым. Можете прокомментировать мои рассуждения?
М.Н.: Действительно, пока Gatsby — инструмент для программистов. Но мы стараемся стать ближе к рядовым пользователям.
Первый шаг — хотим стать удобными для контент-менеджеров. Создать инструменты, которые пользователь без бэкграунда в программировании сможет использовать для публикации и управления контентом. Для этого мы выпустили Gatsby Preview, который позволяет видеть изменения на сайте, когда контент-менеджер редактирует публикации в CMS.
Второй шаг — мы двигаемся в сторону большей доступности для рядового пользователя. Хотим, чтобы он без технических знаний мог создать сайт на Gatsby.
Д.Д.: Чем Gatsby лучше бойлерплейта Create React App? Зачем человеку пользоваться генератором сайтов на React вместо React?
М.Н.: Create React App предоставляет отличную основу для создания приложения на React, но если нужны какие-то продвинутые фичи, это всё надо делать самому. Gatsby предоставляет многое по умолчанию, например, высокую производительность из коробки. Мы постоянно работаем над поддержкой в браузерах, добавляем новые фичи. То есть с Gatsby вы сразу получаете функциональный сайт, а с Create React App только среду для создания сайта.
Д.Д.: На сайте Gatsby есть большой каталог тем или шаблонных сборок. Здесь есть сайты-портфолио, блоги, корпоративные сайты и так далее. Эти темы делает сообщество. Как Gatsby контролирует безопасность и качество этих сборок?
М.Н.: Некоторые темы делает сообщество, некоторые делаем мы сами. Пока у нас нету зафиксированных стандартов и механизмов контроля, поэтому ориентируемся на обратную связь. Жалоб на темы, созданные сообществом, не было.
Д.Д.: Представьте, что к вам обратился знакомый юрист, художник или строитель. Он хочет сделать себе самостоятельно небольшой сайт-визитку и спрашивает вас, каким инструментом воспользоваться. Вы бы порекомендовали человеку разобраться с Gatsby, или всё-таки отправили бы его работать с более простыми инструментами?
М.Н.: Если этот человек хочет или планирует изучать программирование, порекомендую ему Gatsby. Если он не планирует развиваться в этом направлении, пока им будет удобнее работать с более простыми инструментами.
Д.Д.: Как индексируются в поисковиках сайты на Gatsby?
М.Н.: Сайты отлично индексируются. Gatsby генерирует статичный сайт, браузер и поисковый робот видят HTML. Поэтому с индексацией нет никаких проблем.
Д.Д.: Когда я впервые сделал тестовый блог на Gatsby и показал его знакомым, даже далёкие от веб-разработки люди заметили невероятную скорость загрузки страниц. Это одно из основных преимуществ Gatsby. А для каких проектов это важнее всего? Возможно, стоит рекомендовать генератор тем, чья аудитория пользуется смартфонами и мобильным интернетом?
М.Н.: Ключевая идея Gatsby — скорость загрузки страниц. Она важна для любых проектов. Кстати, скорость загрузки — один из факторов ранжирования сайтов в поисковых системах.
Д.Д.: Gatsby написан на React и пользуется популярностью в сообществе React. А насколько интересен этот инструмент специалистам, которые изучают PHP или Python? Им удобнее пользоваться фреймворками, написанными на «родных» языках, или всё-таки Gatsby подходит всем?
М.Н.: Мы сейчас активно работаем с сообществом WordPress, многие разработчики сотрудничают с нами. Это же касается и представителей других известных движков. Те же PHP или Python-разработчики могут использовать Gatsby для фронтенда, а бэкенд делать на привычных языках или фреймворках.
Д.Д.: Чего пока не хватает Gatsby? Есть ли какой-то пробел или пробелы, которые команда пока не закрыла? Что нужно, чтобы Gatsby выстрелил, и нём узнали так же, как о WordPress?
М.Н.: В данный момент нам не хватает удобства использования для простых пользователей. Эту проблему решит платформа, на которой каждый желающий сможет сконфигурировать свой сайт без специальных знаний. То есть мы развиваемся в сторону простых пользователей и хотим, чтобы Gatsby использовали не только программисты.
Д.Д.: Я видел, что Gatsby активно нанимает специалистов. Возможно, это заинтересует кого-то из наших выпускников или продвинутых студентов. Подскажите пожалуйста, кого вы ищете, какие требования предъявляете к кандидатам?
М.Н.: Да, мы активно нанимаем людей. Не требуем опыта работы с Gatsby. Нам важнее опыт работы с opensource-проектами. Прямо сейчас нужны специалисты в области accessibility, GraphQL, JavaScript, Node.js, React.
Д.Д.: Как работает команда Gatsby? Это распределённый коллектив? Как вы общаетесь друг с другом, как планируете рабочие задачи?
М.Н.: Да, это распределённый коллектив. У нас работают специалисты из США и Европы. Общаемся с помощью Skype, регулярно синхронизируемся. Раз в месяц проводим общий созвон. Три раза в год встречаемся лично, компания оплачивает перелёты и проживание.
Д.Д.: «Хекслет» — образовательная платформа, поэтому нашим читателям будет интересно получить рекомендации от опытного разработчика. Поделитесь пожалуйста советами, лайфхаками, своим видением: как стать крутым специалистом и попасть в крутой проект, такой, как Gatsby?
М.Н.: У каждого свой путь в разработку, каждый учится по-своему. Поэтому здесь сложно дать универсальный рецепт. Лично я рано пришёл в React и GraphQL, стал известным в сообществе. Много общался, посещал конференции. Это сыграло роль в моём развитии и карьере.
Gatsby vs Next.js: Взгляд разработчика
Feb 7, 2020 · 8 min read
Введение
React стал популярен до такой степени, что он больше не ограничивается фронтендом. Теперь он используется для разработки:
Существует множество фреймворков и библиотек, созданных поверх React, чтобы улучшить понимание и ускорить разработку.
Теперь все сообщество и проекты, связанные с React, ласково называются React экосистемой. Сегодня мы рассмотрим два известных фреймворка React: Gatsby and Next.js.
Что такое Gatsby?
Gatsby — это современный веб-фреймворк, построе н ный на основе React и GraphQL. Основное внимание фреймворк уделяет встроенной производительности: по умолчанию он создает молниеносно быстрые сайты. Он создает статичную сборку, чтобы сделать сайт быстрее. Это одна из причин, почему Gatsby часто упускают из виду как еще один генератор статичных сайтов.
Несмотря на то, что Gatsby построен на основе React, у него есть собственная экосистема, включающая плагины, темы и стартеры. Gatsby расширяемый по умолчанию. Он создается как статичный сайт во время сборки и размещается как простые HTML-страницы.
Что такое Next.js?
Next.js — еще один популярный фреймворк React. Идея Next.js заключается в том, чтобы создавать React-приложения с обратной связью между сервером и сервером с минимальной конфигурацией или вообще без нее. Производительность не является основным недостатком для Next.js, скорее, это улучшенный опыт разработчиков и уменьшенные хлопоты по созданию полноценных, дружественных SSR веб-приложений.
Next.js также поддерживает статичные сборки, но это не главное. Мы обсудим ограничения, когда будем рассматривать примеры использования.
Понимание SSR и статичных сайтов
Приложения, отображаемые на стороне сервера, по умолчанию оптимизированы для SEO. Рендеринг на стороне сервера ( Server Side Rendering) выполняется быстрее, поскольку он не ждет, пока браузер загрузит JS для отображения контента. SSR требует правильных серверов для отправки ответа каждый раз. В нашем случае Next.js обслуживается с использованием Node серверов.
С другой стороны, статичные сайты работают быстрее, потому что они подают статичные HTML и CSS с сервера без какой-либо обработки во время выполнения. Статичные сайты будут кэшироваться через CDN и обслуживаться быстрее, чем динамические. Статичные сайты также оптимизированы для SEO, если сайт имеет только статичный контент.
Сходство между Gatsby и Next.js
Несмотря на то, что они решают разные проблемы, Gatsby и Next.js имеют много общего.
Кривая обучения для фреймворков не очень крутая, если вы уже знаете, как создавать сайты на основе React, ведь опыт разработчиков стоит на первом месте для этих фреймворков. Мы можем настроить и запустить все очень быстро, а добавление новых функций к простым приложениям происходит легко, потому что оба фреймворка предлагают исчерпывающую документацию. Оба фреймворка поддерживают горячую перезагрузку ( Hot reloading) для более быстрой разработки.
Кэширование и производительность встроены. Нам не нужно беспокоиться о разделении и оптимизации кода: это работает, и по умолчанию они кодируют разделение ( Code splitting) на основе каждого маршрута страницы. Оба фреймворка имеют встроенную маршрутизацию для создания новых страниц.
Они выполняют интеллектуальную загрузку страниц путем асинхронной предварительной загрузки ссылок для следующих страниц при прокрутке страницы. Оценка Lighthouse для хорошо построенных сайтов Gatsby и Next.js будет выдающейся.
Вместо теоретических плюсов и минусов, которые вы можете легко найти в Интернете, мы используем другой подход и определим, какой фреймворк будет лучшим выбором, исходя из рассматриваемой проблемы.
Варианты использования
Каждый из фреймворков особенный, поэтому мы выберем лучший вариант между Gatsby и Next.js для этих случаев использования:
Простой статичный сайт
Здесь количество страниц предсказуемо и не нужно постоянно прогружать через сервер, так как контент будет статичным и одинаковым для всех пользователей. Gatsby создан специально для таких сайтов. Вы можете создавать такие статичные сайты через Next.js, а также с помощью новой функции статичного экспорта.
Тем не менее, Gatsby выигрывает здесь с большим запасом, потому что он предлагает поддержку плагинов для получения контента практически со всех CMS, баз данных, REST API и GraphQL. Он также имеет плагины, которые поддерживают различные форматы данных, такие как JSON, Markdown и MDX ( Markdown with JSX). У него есть простые опции для создания и размещения сайта в любом месте.
Он изолирует данные и сайт так, что даже не программисты могут редактировать контент в другом месте, и он все равно будет скомпилирован как сайт во время сборки.
Next.js не будет обрабатывать ничего, что связано с вашими данными. Вам нужно будет создать свой собственный способ получения данных и отображения их как сайта. Вы можете создать как статичный сайт, но не программисты в вашей команде потребуют от вас помощи в изменении или обновлении контента. Это большая боль, которую решает любая CMS, и Gatsby в полной мере использует это, чтобы легко подключиться к любой CMS через плагин.
Вердикт: Gatsby
Gatsby — наш победитель в создании более быстрых и производительных статичных сайтов. Опыт разработчиков является ключом к такому выводу:
Большие, многопользовательские веб-сайты
Next.js является идеальным выбором для таких нужд, потому что вам нужно показывать динамический контент уникальным пользователям, вошедшим в систему. Мы не можем скомпилировать статичный HTML для каждого пользователя с помощью Gatsby (хотя есть обходной путь, как мы увидим позже в случае использования гибридных сайтов). SSR поможет визуализировать сайт на основе аутентификации.
Так как контент создается большим количеством пользователей и увеличивается при присоединении новых пользователей, компилировать его на статичный сайт во время сборки будет практически невозможно. Гораздо проще показывать соответствующий контент во время выполнения.
Для Gatsby основным недостатком создания таких сайтов является процесс их сборки и время, затрачиваемое на процесс сборки. Пользователи часто хотят видеть свой контент в реальном времени, а не через несколько минут в процессе сборки. А если количество пользователей велико, то это может занять не несколько минут, а несколько часов.
Gatsby работает над оптимизацией этого и уже выпустил начальную поддержку более быстрых сборок в своем коммерческом решении под названием Gatsby Cloud. Но все же это может занять некоторое время, пока мы не получим полную, инкрементальную сборку в реальном времени, и мы также не знаем, решит ли Gatsby выпустить эту функцию как часть своего открытого предложения в ближайшее время.
Вердикт: Next.js
Для веб-сайтов с несколькими пользователями, которые получают доступ к контенту и редактируют его, лучше строить с помощью Next.js:
В таких случаях построение временных рамок не будет работать хорошо
Приложения на стороне клиента (SPA/MPA)
Здесь скорость и быстрое время отклика для пользователя являются ключевыми моментами, SEO отходит на второй план. Для таких сайтов нет явного победителя между Gatsby и Next Js. Ниже мы увидим в деталях, как и то, и другое сыграет свою роль в разработке таких веб-приложений.
Gatsby для динамических веб-приложений
До сих пор мы говорили, что Gatsby строит во время сборки и обслуживает статичный сайт. На самом деле это только полуправда. Почему?
Несмотря на то, что Gatsby обслуживает статичный сайт, он также повторно обрабатывает ( re-hydrate) React на странице на стороне клиента. Таким образом, вы можете создать любое клиентское приложение, используя Gatsby, так же, как и приложение create-react-app ( CRA). Так почему же вы выбираете Gatsby вместо CRA?
Gatsby поддерживает разделение кода по умолчанию. В CRA, вам нужно будет сделать это самому. CRA также не имеет встроенного механизма для поддержки многостраничных веб-приложений. Это возможно, но мы должны сделать это вручную. С другой стороны, Gatsby поддерживает многостраничные приложения.
Теперь рассмотрим пример, в котором у вас есть три разных набора пользователей с тремя разными UX-дизайнами для этих пользователей.
Многостраничная природа Gatsby легко помогает вам изолировать и отправить этих пользователей на соответствующие страницы после аутентификации. В CRA, вам нужно обрабатывать это через ваш маршрутизатор. Gatsby имеет встроенную поддержку маршрутизации на стороне клиента. CRA не поставляется с реализацией маршрутизатора, но добавить его несложно.
Предварительная настройка следующих ссылок и активов в Gatsby проста и ускоряет загрузку страницы. Столь высокого уровня оптимизации достаточно сложно добиться в CRA самостоятельно.
Таким образом, в целом, построить клиентское приложение, отрисовываемое с помощью Gatsby, вполне возможно. Так что никогда не думайте о Gatsby как о статичном генераторе сайтов — он делает больше. Это полный каркас для создания современных веб-приложений.
Next.js для динамических веб-приложений
Теперь давайте посмотрим, как Next.js помогает создавать современные динамические веб-приложения. До сих пор мы знаем, что Next.js способен на SSR, что правда, но это еще не все. Он также повторно обрабатывает ( re-hydrate) React на стороне клиента, поэтому вы можете построить полное клиентское приложение React поверх Next.js.
Большинство преимуществ аналогичны Gatsby, но у него есть еще несколько преимуществ при использовании SSR. Например, вы можете отрисовывать статичный сайт и делать всю свою логику на стороне клиента, так же, как и Gatsby приложения или CRA. Так что технически вам не нужно использовать возможности SSR от Next.js; вы можете построить полное, клиентоориентированное SPA или многостраничное приложение, используя Next.js.
Самым большим преимуществом Next.js является то, что он предлагает лучшее из обоих миров. Он имеет возможности SSR наряду с возможностями клиентских приложений. Он поддерживает разделение кода на страницы, а также позволяет динамический импорт для разделения кода на куски в зависимости от потребностей.
Первая отрисовка пользовательского интерфейса с клиентскими приложениями обычно медленная, а затем маршрутизация будет обрабатываться быстрее браузером. Но с помощью SSR мы можем загружать для отрисовки пользовательского интерфейса быстрее, чем любой клиентский фреймворк, а затем последующие страницы будут загружаться по клиентским маршрутам.
Таким образом, мы можем получить преимущества обоих миров в Next.js (т.е. и SSR, и CSR).
Вердикт: ничья
Таким образом, для динамических веб-приложений Gatsby и Next.js одинаково эффективны. Next.js немного выигрывает в первой отрисовке пользовательского интерфейса.
Гибридные веб-приложения
Гибридные веб-приложения являются последним раундом в нашем примере. Мы уже кратко рассказывали о том, что Next.js предлагает лучшее из обоих миров в том, что он визуализирует пользовательский интерфейс страницы с помощью SSR, а затем передает ответственность за данные клиентскому приложению React. Но когда же нам понадобятся обе эти функциональности?
Если вы заходите на свою страницу Twitter, не войдя в систему, он загружает начальные твиты через SSR. Если вы прокручиваете страницу вниз, она загружает следующий набор твитов через клиентскую сторону. Но если вы входите в систему, она просто загружает оболочку приложения, а затем JavaScript на стороне клиента загружает содержимое твитов.
Таким образом, внутри одного приложения он поддерживает как SSR для посетителей, так и CSR для зарегистрированных пользователей. То же самое верно и для большинства больших социальных сетей и веб-сайтов сообществ.
Вердикт: Next.js
Для гибридных веб-приложений, которые не требуют SEO, способны как Gatsby, так и Next.js. Но для приложений, которые требуют SEO для общедоступного динамического контента, Next.js является лучшим вариантом.
Теперь давайте рассмотрим другой вариант использования гибридного веб-приложения и сайта в одной кодовой базе.
Gatsby.js в деталях
Как известно на одних бойлерплейтах далеко не уедешь, поэтому приходится лезть вглубь любой технологии, чтобы научиться писать что-то стоящее. В этой статье рассмотрены детали Gatsby.js, знание которых позволит вам создавать и поддерживать сложные вебсайты и блоги.
Предыдущая статья о том как создать и опубликовать личный блог используя JAM-stack
Темы рассмотренные далее:
Подготовка
Если в консоли нет ошибок, а в браузере по пути http://localhost:8000 виднеется «Hello world!» значит всё работает исправно. Можно попробовать изменить содержимое файла /src/pages/index.js, чтобы проверить hot-reload.
Структура страниц и роутинг
Чтобы создать страницу в Gatsby, достаточно просто поместить новый файл в папку /src/pages, и он будет скомпилирован в отдельную HTML-страницу. Важно заметить, что путь к этой странице будет соответствовать фактическому пути с названием. Например, добавим ещё несколько страниц:
Контент пока не важен, поэтому можно использовать любой текст, чтобы различать страницы
Проверяем в браузере:
Вот таким образом, можно структурируя файлы, сразу решать вопросы роутинга.
Также существует специальный createPage API, с помощью которого можно более гибко управлять путями и названиями страниц, но для работы с ним нам понадобится понимание работы данных в Gatsby, поэтому рассмотрим его чуть дальше в статье.
Страницы созданы, ссылки добавлены, получается что с навигацией закончили.
Компоненты, шаблоны и их взаимодействие
Как известно, в любом проекте всегда есть повторяющиеся элементы, для вебсайтов это хедер, футер, навигационная панель. Также страницы, вне зависимости от контента, строятся по определённой структуре, и так как Gatsby это компилятор для React, здесь используется тот же компонентный подход для решения этих проблем.
Создадим компоненты для хедера и навигационной панели:
и добавим их в /src/pages/index.js
Всё работает, но нам нужно импортировать Header и Sidebar на каждую страницу отдельно, что не очень то и удобно, и чтобы решить этот вопрос достаточно создать layout-компонент, и обернуть им каждую страницу.
Gatsby layout == React container
да-да, именно нестрогое равенство, потому что это «почти» одно и тоже
/src/pages/index.js (и все остальные страницы)
Готово, смотрим в браузер:
Почему в проекте все названия файлов с маленькой буквы? Для начала определимся что namespacing для React происходит из того, что «каждый файл это класс, а класс всегда называется с большой буквы». В Gatsby файлы по прежнему содержат классы, но есть одно «но» ― «каждый файл является потенциальной страницей, а его название ― URL к этой странице». Комьюнити пришло к выводу о том, что ссылки вида http://domain.com/User/Settings это не comme-il-faut и утвердили kebab-case для названий файлов.
Работа с данными
Теперь, когда структура сайта готова, можно переходить к наполнению контентом. Классический «хардкод» подход не устраивал создателей JAM-стека, так же как и «рендерить контент из AJAX-запросов» и поэтому они предложили заполнять сайты контентом во время компиляции. В случае с Gatsby за это отвечает GraphQL, который позволяет удобно работать с потоками данных из любых источников.
Рассказать про GraphQL в двух словах невозможно, поэтому желательно изучить его самостоятельно либо подождать моей следующей статьи. Детальнее о работе с GraphQL можно почитать здесь.
Для работы с GraphQL, со второй версии, в пакете gatsby есть компонент StaticQuery, который может использоваться как на страницах, так и в простых компонентах, и в этом его главное отличие от его предшественника ― page query. Пока что наш сайт не соединён с какими-то источниками данных, поэтому попробуем вывести метаданные страниц, для примера, а затем перейдем к более сложным вещам.
Чтобы построить query нужно открыть http://localhost:8000/___graphql, и пользуясь боковой панелью с документацией найти доступные данные о сайте, и не забудьте про автодополнение.
Теперь мы используя query получаем данные о страницах, которые рендерим в панели навигации, и больше не нужно переживать по поводу того что ссылка не будет соответствовать названию, потому что все данные собираются автоматически.
По факту это все данные, которые могут быть на нашем сайте без использования сторонних плагинов и без старого доброго «хардкода», поэтому мы плавно переходим в следующую тему нашей статьи ― плагины.
Плагины
По своей сути Gatsby это компилятор с кучей плюшек, которыми как раз и являются плагины. С помощью них можно настраивать обработку тех или иных файлов, типов данных и различных форматов.
Создадим на корневом уровне приложения файл /gatsby-config.js. который отвечает за конфигурацию компилятора в целом, и попробуем настроить первый плагин для работы с файлами:
Конфигурация в файле /gatsby-config.js:
Помните мы говорили про «правильный» импорт картинок в Gatsby?
Установка плагинов для стилизации:
Стилизация приложения
Приступим к стилизации приложения используя различные подходы. В предыдущем шаге мы уже установили плагины для работы с SASS, styled-components и библиотекой typography.js, при этом важно отметить что css.modules поддерживаются «из коробки».
Начнём работу с глобальных стилей, которые, как и остальные вещи относящиеся ко всему сайту, должны быть сконфигурированы в файле /gatsby-browser.js:
В силу разных причин, тенденции последних лет склоняются в сторону «CSS in JS» подхода, поэтому не стоит злоупотреблять глобальными стилями и лучше ограничиться указанием шрифта и переиспользуемых классов. В этом конкретном проекте планируется использование Typography.js для этих целей, поэтому глобальные стили останутся пустыми.
Вы уже могли заметить изменения внешнего вида сайта после добавления gatsby-plugin-typography в конфигурацию ― это потому что был применён его пресет по умолчанию, а сейчас мы сконфигурируем его под себя.
Можно выбрать любой другой пресет из списка или создать свой собственный используя API пакета (пример конфигурации официального сайта Gatsby)
И в зависимости от выбранного пресета, глобальный стиль сайта будет изменён. Каким подходом настраивать глобальные стили решайте сами, это вопрос личных предпочтений и различий с технической точки зрения нет, а мы переходим к стилизации компонентов используя styled-components:
Добавим файл с глобальными переменными /src/utils/vars.js
Уже существующие элементы стилизованы, и пришло время связать контент с Contentful, подключить маркдаун плагин и сгенерировать страницы используя createPages API.
Детальнее о том как связать Gatsby и Contentful читайте в предыдущей статье
Удаляем папку /src/pages со всеми файлами внутри и создаем новый файл, для управления узлами в Gatsby:
Создаём template-файл, который будет основой для генерируемых страниц
/src/templates/index.js
SEO-оптимизация
С технической стороны сайт можно считать готовым, поэтому давайте поработаем с его мета-данными. Для этого нам понадобятся следующие плагины:
Теперь title сайта будет всегда соостветствовать названию статьи, что будет существенно влиять на выдачу сайта в результатах поиска конкретно по этому вопросу. Сюда же можно легко добавить с описанием каждой статьи отдельно, этим дав возможность пользователю ещё на странице поиска понять о чём идет речь в статье, вообщем все возможности SEO теперь доступны и управляемы в одном месте.
Настройка PWA
Gatsby разработан, чтобы обеспечить первоклассную производительность «из коробки». Он берёт на себя вопросы по разделению и минимизации кода, а также оптимизации в виде предварительной загрузки в фоновом режиме, обработки изображений и др., так что создаваемый вами сайт обладает высокой производительностью без какой-либо ручной настройки. Эти функции производительности являются важной частью поддержки прогрессивного подхода к веб-приложениям.
Но кроме всего вышеперечисленного существуют три базовых критерия для сайта, которые определяют его как PWA:
Первый пункт не может быть решён силами Gatsby, так как домен, хостинг и протокол это вопросы деплоймента, и никак не разработки, но могу порекомендовать Netlify, который решает вопрос https по умолчанию.
Переходим к остальным пунктам, для этого установим два плагина:
и настроим их /src/gatsby-config.js
Вы можете настроить свой манифест используя документацию, а также кастомизировать стратегию service-workers, перезаписав настройки плагина.
Никаких изменений в режиме разработки вы не заметите, но сайт уже соответствует последним требованиям мира web, и когда он будет размещён на https:// домене ему не будет равных.
Вывод
Пару лет назад когда я впервые столкнулся с проблемами вывода в интернет React-приложения, его поддержки и обновления контента, я и не мог представить что на рынке уже существовал JAM-stack подход, который упрощает все эти процессы, и сейчас я не перестаю удивлятся его простоте. Gatsby решает большинство вопросов влияющих на производительность сайта просто «из коробки», а если ещё немного разобравшись в тонкостях настроить его под свои нужды, то можно получить 100% показатели по всем пунктам в Lighthouse, чем существенно повлиять на выдачу сайта в поисковых системах (по крайней мере в Google).