Gatsbyjs - отличное дополнение в арсенале разработчиков React. Однако, как и в случае с любым другим инструментом, важно знать, когда к нему обращаться. В LeanJS с января 2018 года мы использовали Gatsby в трех проектах, два из которых в настоящее время находятся в разработке, а один нам пришлось перенести. Мы хотели бы поделиться своим опытом и выводами :-)

Соревнование

В начале января у нас был проект, в котором нам нужно было перенести литературный сайт с его исходной плоской файловой системы, чтобы иметь настраиваемый пользовательский интерфейс, обеспечивающий удобство использования, соответствующее его престижности. Нам передали экземпляр Wordpress со всеми данными, которые были перенесены на 😐. Наш стандартный стек - это React с SSR, GraphQL и бессерверной серверной частью. К счастью, поскольку graphQL прекрасен, вы можете просто обернуть существующий restAPI (например, Wordpress) и использовать его через graphQL, подход, который мы использовали раньше, поэтому мы были уверены в том, что выбрали этот подход.

Использование Gatsby с большим набором данных (v1)

Поскольку Гэтсби только начинал выходить на сцену, мы создали быстрый прототип, используя плагин gatsby-source-wordpress, чтобы проверить, насколько это жизнеспособный вариант. В нашем случае у нас было ~ 9000 бит контента (сообщений), что, по общему признанию, было амбициозным, учитывая, что оно было протестировано с помощью 900. Но эй, престо, это сработало! Таким образом, все преимущества Гэтсби, такие как нестандартное разделение кода и молниеносная навигация между страницами, выглядели так, как будто они были в пакете. Время сборки составляло около 5 минут, что казалось разумным для в основном статичного сайта, который не нужно было перестраивать чаще, чем пару раз в неделю.

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

Большие проблемы

Те, кто хоть немного работал с Гэтсби, могут заметить, что существует большая разница между запуском чего-то в «разработке» и тем, что работает, когда вы запускаете сборку. Проще говоря, то, что вы можете запускать что-то локально с помощью gatsby develop, не означает, что оно будет построено без ошибок. Конечно, решение этой проблемы - регулярно запускать сборку, а затем использовать базовый локальный сервер для проверки всего.

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

Когда вы начинаете добавлять много стилей (с помощью стилизованных компонентов) и использовать другую библиотеку с открытым исходным кодом для добавления функциональности, время сборки начнет резко увеличиваться. В нашем случае оно составило примерно 25 минут. На этом этапе больше нецелесообразно постоянно запускать сборки, и устранение ошибок становится все труднее. Вторая большая проблема заключается в том, что из-за того, как работает статическая сборка, все хранится в памяти во время сборки, поэтому вам нужно иметь большой объем оперативной памяти для ее обработки. После определенного момента (после добавления дополнительных библиотек) на всех компьютерах не хватало памяти при попытке создать сайт.

RangeError: Maximum call stack size exceeded

Сейчас это довольно известная проблема, и вы можете прочитать о ней подробнее в этой ветке. Однако, чтобы сэкономить время на чтении, ответ заключается в том, что он решен в версии 2 (в настоящее время все еще находится в бета-версии), поскольку они больше не используют тот же процесс статической сборки webpack, который вызывал проблему.

Однако еще в январе V2 еще не был на горизонте, и нам нужно было уложиться в сжатые сроки. Мы приняли решение переместить весь сайт gatsby в стандартное приложение create-response-app с рендерингом на стороне сервера и использовать GraphQL для потребления данных wp через wp-graphql.

Это было не из легких дел, но в итоге мы поместили его в наш стандартный стек примерно за 4 дня 😅.

Урок усвоен

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

Экосистема React потрясающая и очень однозначная. Это здорово, но это означает, что нам, как инженерам, нужно быть более подготовленными к принятию решений и полностью понимать все технологии, которые работают вместе. Когда у вас очень сжатые сроки, легко попасть в ловушку, желая пойти по пути фреймворка, где соглашение важнее конфигурации поможет вам выполнить работу быстрее. Однако, когда кремень ударяется о металл, вы должны быть уверены, что сможете быстро изменить его и использовать больше ванили. Хотя Гэтсби - отличный инструмент, нет сомнений в том, что он более самоуверенный со всеми присущими ему преимуществами (и недостатками). вместе с этим.

Мнение против ванили

Возможно, вы думали, что в итоге всегда нужно использовать как можно ваниль. Однако современная программная инженерия должна быть более тонкой, если вы хотите достичь хорошего баланса скорости и качества. В ReactJS Academy мы всегда настаиваем на том, что вы должны быть хорошим разработчиком JavaScript, если хотите стать хорошим разработчиком React. Как однажды сказал Кайл Симпсон студентам на одном из наших буткемпов:

«Вы должны стремиться быть экспертом на своем уровне стека и иметь очень хорошее практическое знание уровня ниже».

Для нас это означает быть экспертом в экосистеме React и очень хорошо разбираться в ванильном JS. В противном случае вы не можете рассчитывать, что что-то быстро исправит, если что-то пойдет не так, что в конечном итоге может привести к негативным последствиям для всех, кого это касается. Это снова было подчеркнуто во время перехода, не зная, как реализовать SRR в React, мы либо продолжали бы бороться, либо получили бы худший результат. Вы можете прочитать, как сделать SSR в React с краткими инструкциями здесь: https://github.com/leanjscom/fb-messenger/tree/SSR-part1#reactjs-facebook-messenger

Итак, когда и где мы будем использовать Гэтсби?

Этот опыт с Гэтсби на проекте не был чем-то, что нас оттолкнуло, во всяком случае, наоборот. Преимущества довольно очевидны. Если вы - команда, которая хорошо разбирается в быстром создании приложений с архитектурой на основе компонентов React, когда вы сталкиваетесь с тяжелым статическим сайтом, Gatsby - отличный вариант. Поэтому, когда мы решили, что пришло время переделать сайты ReactJS Academy и LeanJS (ранее Jekyll), мы знали, куда обращаться. В обоих случаях сайты не являются сложными, но, создавая с помощью Gatsby, мы можем интегрировать весь наш опыт и рабочие процессы React, чтобы быстро создавать и тестировать сайты. Когда нет большого набора данных или сложной интеграции через плагин, для разработчиков React, которые хотят создать презентационный сайт, такой как блог или резюме, Gatsby - отличный вариант.

Заключение

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

Расскажите нам о своем опыте работы с Gatsby и другими инструментами в экосистеме React в комментариях 😎