… А также с Next.js + React ❤️️❤️️❤️️

Если вы ищете конечный продукт, c оставьте это репо здесь - npm i для установки, npm start для локального запуска и npm run publish для отправки в веткуgh-pages (после добавления источника в качестве собственного репозитория). 😄 Вот как это должно выглядеть

Предисловие

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

Со времени учебы в колледже я использовал (стандартный) уровень бесплатного пользования Google App Engine для размещения собственного веб-сервера (бесплатно в течение 28 часов микроэкземпляра в день). Со временем я обнаружил страницы GitHub и простоту развертывания статических страниц на страницах GitHub. Это подходило моему сайту, который в основном обслуживал статический контент, и я сразу же увлекся страницами GitHub.

Существующие генераторы статических страниц

Когда я впервые начал работать со страницами GitHub, я использовал middleman-gh-pages. Разработка велась с использованием Embedded Ruby (ERB). Это было то же самое, что и разработка в Ruby (и Ruby on Rails), за исключением того, что он использовался взаимозаменяемо с HTML из-за того, что он использовался для шаблонов рендеринга. Еще одним популярным выбором, поддержанным GitHub, был Jekyll, использующий язык шаблонов под названием Liquid.

Простота использования страниц GitHub проиллюстрирована при использовании middleman-gh-pages. Он включает одну команду для загрузки локального сервера разработки (при отслеживании изменений файлов) и одну команду для развертывания или обновления, что позволяет очень легко переключаться между разработкой и развертыванием .

Одностраничное приложение (SPA) + решение на JavaScript?

Как насчет использования чего-то, что поддерживается современными библиотеками JavaScript в качестве языка шаблонов, а также поддерживает конфигурацию SPA?

Причина, по которой я выбрал решение на JavaScript, заключалась в том, что во фронтенд-разработке преобладал JavaScript, и, к тому же, он был наиболее часто используемым языком с 2014 по 2018 год. Самые популярные темы, отмеченные тегами из проектов, также относятся к React и Angular, популярным проектам. которые используются для веб-разработки.

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

Тем не менее, мой собственный опыт SPA обычно не похож на статические веб-страницы. Angular, React-Router и Next.js - это фреймворки и инструменты, которые являются отличными примерами для магистралей SPA. Обычно они поддерживаются каким-либо сервером (Экспресс или другие подобные серверные фреймворки).

При беглом поиске я не смог найти что-то, что соответствовало бы шаблону JavaScript-фреймворка, обычно используемого для страниц GitHub. Однако мое внимание привлекло кое-что еще:

Интересный. Я использовал Next.js в работе вместе с Express для веб-приложений. Но как статическое HTML-приложение? Для меня это был новый опыт.

Next.js поддерживает маршруты, на которые напрямую ссылаются .js файлы, такие как статические файлы HTML (pages/index.html маршруты к / в статическом HTML-приложении. В Next.js pages/index.js делает то же самое). Это делает его идеальным кандидат на понимание и поддержку статических путей, даже не зная о фреймворке Next.js.

Итак, задание здесь будет таким: «Можем ли мы создать статический шаблон фреймворка HTML с помощью Next.js»? Я также хотел имитировать те же одноэтапные команды разработки и развертывания middleman-gh-page, чтобы упростить использование этого шаблона.

Решение, разбитое на более мелкие проблемы

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

Разработка

В разделе разработка мы хотим решить еще две подзадачи - настроить сервер разработки и интегрировать инструменты, которые мы хотим использовать (например, Sass).

Для одноэтапной разработки в Next.js уже предусмотрены функции для этого при запуске сценария thenext. Он также следит за изменениями файлов и при необходимости перестраивает, что делает его отличным кандидатом здесь. Однако это не работает, если на next.config.js вносятся изменения в модули и подключаемые модули webpack.

Я также пробовал использовать nodemon, чтобы следить за изменениями на next.config.js. Несмотря на то, что вышеуказанная проблема решена успешно, в процессе сборки будет несколько секунд простоя. Поскольку next.config.js не предназначен для частого изменения, я решил придерживаться собственного решения Next.js. Однако вы можете выбрать вариант nodemon, добавив следующее в вашу package.json конфигурацию.

Для инструментов мы можем настроить стандартные инструменты, такие как Sass, и ресурсы изображений, на которые ссылаются компоненты нашей страницы при создании приложения. Это стандартные требования, которые обычно предъявляются к среднему приложению Next.js, а его конфигурация в значительной степени общедоступна (также легко найти в Интернете), а именно:

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

Развертывание

Чтобы добиться одноэтапного развертывания, мы должны рассмотреть несколько проблем. Самым важным здесь является конвейер создания ресурсов (HTML, JS, CSS) и отправка созданных ресурсов на GitHub. Вот список всех подзадач, которые я собираюсь решить здесь.

  1. Создание статических активов:
  • Минификация активов
  • Сжатие активов

2. Развертывание:

  • Перенос из каталога ресурсов сборки в другую ветку
  • Добавление настраиваемого «базового пути» для статических страниц, не начинающихся с корня

3. Очистка

1. Создание статических активов

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

К счастью, это уже присутствует в функциях сборки Next.js при запуске next build, что делает эту проблему решенной.

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

Для сжатия ресурсов мы можем использовать сжатие-webpack-plugin и применить его к подключаемым модулям сборки webpack в next.config.js, чтобы получить результат выше. Следующая конфигурация может быть добавлена, и ее должно быть достаточно для достижения желаемого результата.

Обратите внимание, что страницы GitHub уже поддерживают сжатие gzip на лету. Приведенная выше настройка позволяет нам использовать это за пределами страниц GitHub, особенно когда заголовок ответа Content-Encoding: gzip является требованием для ресурсов.

2. Развертывание на GitHub

После того, как статические ресурсы созданы, мы хотим посмотреть на продвижение ресурсов. Как работают страницы GitHub, статические ресурсы должны быть перенесены в одну из двух заранее определенных ветвей, master или gh-pages. Используя инструмент git CLI, мы можем проследить за перемещением содержимого каталога сборки в ветвь gh-pages. Это потребует ряда git инструкций, которые мы должны интегрировать как часть процесса сборки.

Вместо того, чтобы создавать функциональные возможности в этом шаблоне, я решил переместить решение в отдельный узел узла, поскольку это было чем-то, что потенциально могло быть использовано в другом месте. Конечным результатом стал созданный мной узел узла под названием subpath-as-branch. Это было использовано как отдельная инструкция, которая используется непосредственно из этого приложения, предоставляя каталог dist в качестве пути для загрузки ресурсов и ветку gh-pages для загрузки ресурсов.

Добавление «базового пути»

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

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

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

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

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

После добавления вышеупомянутого пути к активам следовало скорректировать для достижения следующего:

Второй критерий - убедиться, что все ссылки в этом SPA также содержат базовый путь. Для этого мы можем обернуть next/link компонент, чтобы ввести базовый путь.

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

Как только значение становится доступным для publicRuntimeConfig, мы можем использовать его из нашего предполагаемого компонента, который обертывает next/link:

Использование BasePathLink - это простой вопрос использования его как компонента Link в next/link:

3. Очистка

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

Чтобы завершить процесс развертывания, мы можем объединить то, что мы реализовали выше, и выполнить его с помощью одной команды.

Исходя из вышеизложенного, npm start будет первым шагом в развитии, как мы обсуждали ранее. npm run publish будет объединять все этапы развертывания, которые мы только что обсудили, включая создание ресурсов и передачу ресурсов в ветвь gh-pages.

Вот и все, ребята!

Итак, можем ли мы создать статический генератор SPA на JavaScript для страниц GitHub или ему подобных. Да, с Next.js.

Можем ли мы создать одноэтапную разработку и одноэтапное развертывание на страницах GitHub для простоты использования. Определенно!

Если вам интересно, вот конечный продукт: https://github.com/Weiyuan-Lane/spa-github-page-template.