PokéProject: от статического HTML до React и Nuxt.

PokéProject: от статического HTML до React и Nuxt.

Это история моего пути разработки с PokéProject. Надеюсь, это не полная история, и в будущем еще предстоит рассказать еще много чего. Это не рассказ об идеальном жизненном цикле разработки, и я уверен, что если бы я снова начал этот проект с нуля, было бы сделано изрядное количество альтернативных вариантов.

Готовый? Поехали.

Идея 💡✨

Первоначальная идея PokéProject заключалась в том, чтобы использовать классические игры про покемонов моего детства в качестве вдохновения для кодовых имен в моих проектах на работе, как своего рода ностальгическую инъекцию веселья в повседневную рутину.

Кодовые имена проектов - довольно важная вещь в MMT Digital - каждая проектная команда выбирает себе кодовое имя в качестве связующего звена во время первого спринта - и часто доходят до того, что поддерживают это с помощью сувениров ограниченного выпуска, таких как фирменные кружки, футболки или аналогичные предметы. Одна из этих стартовых встреч по проекту вдохновила меня на идею, и с тех пор она обрела форму.

Технический подход 🤔

Я в первую очередь Front End разработчик и предпочитаю JavaScript. Для самой первой версии PokéProject я решил, что все, что мне нужно, это статический HTML, CSS и простой ванильный JavaScript. Никаких фреймворков, никаких шаблонов Bootstrap и, конечно же, ничего, что могло бы отвлечь меня от основной цели проекта - генерации кодовых имен.

Плато прогресса 📉

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

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

Необходимость восстановления

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

Когда я говорю большие и лучшие вещи, я говорю о нескольких ключевых функциях, которых, как мне казалось, не хватало в PokéProject, и которые ограничивали его шансы на успех. В первую очередь это были:

• Интеграция с социальными сетями.
• Ремонтопригодность и долгосрочная масштабируемость исходного кода.
• Ограничения моего решения для маршрутизации URL-адресов и сложность его развертывания и обслуживания.
• Размер загрузки веб-сайта и его источников данных.

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

Статический HTML

Статический HTML в конечном итоге быстрее, чем что-либо, динамически генерируемое на стороне сервера. Сервер разработки PokéProject использует NGINX для обслуживания статического HTML, он быстрый и масштабируемый. Предыдущий опыт подсказывает мне, что проблем с нагрузкой или потреблением ресурсов не возникнет - если мы получим достаточно трафика, чтобы вызвать проблемы, это не будет NGINX, который откажет первым.

Настройка, на которую я пошел, была очень малобюджетной - весь мой «веб-сайт» представлял собой один файл index.html, который NGINX был настроен для обслуживания по умолчанию, когда файл, на который имеется прямая ссылка, не существует на сервере. Независимо от запрошенного URL-адреса будет возвращено то же содержимое файла index.html, и клиентский JavaScript оценит свойство window.location, чтобы определить, какой контент отображать на экране. Малобюджетный, полностью индивидуальный подход к маршрутизации URL-адресов - простой, но эффективный. Или изначально работал.

Проблемы со статическим HTML

Проблемы со статическим HTML действительно начали проявляться, когда я захотел продвинуть PokéProject в социальную сферу и упростить совместное использование контента на таких платформах, как Twitter и Facebook. При добавлении ссылок на эти платформы они запрашивают данные о связанной странице и используют их для предварительного просмотра ссылки. Проблема в том, что мои статические HTML-страницы - это, по сути, один и тот же HTML-файл, обслуживаемый в ответ на любой URL-запрос, и содержимое оценивается и отображается на стороне клиента на основе содержимого, что далеко не идеально для этих предварительных просмотров веб-сайтов на основе сервера. Мне действительно нужен был другой, подходящий HTML-код для обслуживания каждого URL-запроса - по сути, мне нужен был рендеринг на стороне сервера.

Вариант 1. Более статический HTML

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

В определенной степени я уже делал что-то подобное - для первой версии интеграции карт Twitter мне нужно было создать актуальные версии рендеринга холста в формате JPG, поэтому я создал сценарий для одноразового создания карты 721 Pokémon. было необходимо для его поддержки, но создание потенциально тысяч копий статических HTML-файлов в соответствующих структурах URL-адресов казалось неправильным, не в последнюю очередь потому, что время, необходимое для их обновления на сервере для каждого выпуска, было непомерно высоким.

Другой альтернативный вариант, который я выбрал, заключался в дальнейшем исследовании идеи построения PokéProject в надлежащей структуре, в идеале с поддержкой серверного или «универсального» рендеринга.

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

✨Принятие React✨

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

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

Проблемы с React

Проблема заключалась в том, что мое готовое приложение React не поддерживало рендеринг на стороне сервера, что было своего рода основной причиной его внедрения.

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

Нет проблем, - подумал я и выбрал другой. Большая часть структуры была той же, и я провел вечер, портируя код, только чтобы обнаружить, что этот шаблон использует React и Redux. Redux - это совсем другое дело - они даже советуют не брать их сразу сразу на своем сайте. Прыгнул вперед во времени и потратил еще несколько дней, пытаясь понять, как это работает, а у меня до сих пор нет приложения React с содержимым, отображаемым на стороне сервера, поэтому я в отчаянии вернулся к исследование стартовых шаблонов React для одного, который: а) достаточно простой для понимания без большого количества чтения документации и б) поддерживает рендеринг на стороне сервера, горячую перезагрузку модуля и все остальное, что, по моему мнению, должно быть в проекте.

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

Признавая поражение

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

Поиск Vue.js

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

✨Принятие Nuxt✨

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

В буквальном смысле я смог найти, загрузить, установить и иметь рабочий локальный сервер разработки и производства, работающий как доказательство концепции с API на основе Express, разделением кода веб-пакета, горячей перезагрузкой модуля и всем остальным менее чем за час. Учитывая, что я не смог достичь того же результата за две недели разработки с помощью React, я довольно быстро подсел на Nuxt.

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

С тех пор я полностью заменил PokéProject версией на основе Nuxt и очень рад тому, что готовит будущее.

Первоначально опубликовано на www.psyked.co.uk 10 апреля 2017 г.