📚Lecture Notes
Я считаю, что лучшее место для публикации dapps - это GitHub Pages, не только для разработки, но и для производства. GitHub Pages - это бесплатный сервис для проектов с открытым исходным кодом, который позволяет публиковать статические веб-сайты на основе HTML/CSS/JS непосредственно из репозитория GitHub.
Поскольку все dapps всегда должны быть с открытым исходным кодом, все приложения квалифицируются здесь. GitHub Pages также поддерживает пользовательские домены, поэтому конечный результат будет идентичен другим службам публикации производства. Еще одно преимущество GitHub Pages заключается в том, что он поддерживает только статические веб-сайты - он работает только на стороне клиента. Нет бэкэнда, который может запускать код или рендеринг на стороне сервера. Это ограничение на самом деле является функцией для нас, потому что децентрализованные приложения никогда не должны зависеть от внутренних сервисов, так как они централизованы.
Последняя важная функция для GitHub Pages, которая делает ее очень подходящей для dapps, - это ее опая на репозитории Git, которая дает нам множество бесплатных функций управления сообществом. Например, группа сопровождающих может легко поделиться привилегией развертывания веб-сайта, потому что все они имеют определенный доступ к репозиторию. Сотрудники из сообщества могут отправлять запросы на включение, и они могут быть объединены. Члены сообщества могут влиять на dapps в режиме реального времени. И, наконец, если кто-то из сообщества не доволен тем, как управляется dapp, он всегда может разветвить первоначальный репозиторий GitHub и создать свой собственный независимый клиент, который также может быть опубликован на страницах GitHub в один клик.
Развертывание на страницах GitHub
У нас есть наше веб-приложение локально. Как мы только что обсуждали, это только передняя часть. Внутремная часть - это смарт-контракт нашего dapp. Давайте развернем на страницах GitHub.
Во-первых, нам нужно создать новый репозиторий, чтобы ввести наш код. Но прежде чем мы начнем, давайте поговорим немного больше о том, как наш репозиторий будет перенесен на веб-страницу.
Как вы могли догадаться, страницы GitHub тесно связаны с вашей учетной записью GitHub. Итак, давайте предположим, что у вас есть имя пользователя; мое - @markokhman, поэтому я ввожу его. Затем вы вводите имя репозитория, которое будет доступно в качестве первой части пути. Давайте назовем это first_contract_front_end. Теперь мы можем нажать Создать репозиторий.
Теперь мы начнем комировать наш код по частям. Конечно, мы можем сфиксировать весь код сразу, но некоторые его части должны рассматриваться особым образом. Мы копируем URL-адрес нашего репозитория GitHub и возвращаемся в нашу IDE, чтобы инициировать наш репозиторий Git. На странице быстрой настройки вы можете найти команды, которые помогут вам:
Давайте вернемся к GitHub и немного поговорим о том, как работают страницы GitHub. По сути, у нас есть имя пользователя и имя нашего репозитория. Как это будет работать с веб-сайтом, размещенным на страницах GitHub позже? Markokhman, мое имя пользователя, будет использоваться в качестве поддомена. Затем я добавляю github.io в качестве домена, а затем у меня будет имя моего репозитория:
markokhman.github.io/first_contract_front_end/
Создание нового файла манифеста
Здесь наш веб-сайт скоро будет опубликован, и теперь мы должны подготовиться к нему. Но прежде чем мы продолжим, давайте вспомним, что вы также должны сделать манифест. Как вы помните, вы все еще используете мой файл манифеста.
Как создать свой собственный файл манифеста, который также доступен в общедоступной папке? Перейдите к файлу main.tsx. Там вы можете увидеть URL-адрес моего файла манифеста. Давайте создадим новый, который будет помещен в общедоступную папку, и назовем его tonconnect-manifest.json.
Мы знаем структуру, это будет URL. Я все еще буду пользоваться своим сайтом:
"url": "https:///join.toncompany.org"
Затем мы идем с именем:
"name": "TON&Co. Tutorial"
А затем идет иконка URL. Мы также хотим, чтобы он был частью нашего хранилища. Так что теперь я собираюсь поместить файл значка здесь, в общедоступную папку, но позже я на самом деле составлю здесь правильный URL-адрес, который будет ссылаться на этот файл, как только мы его развернем. Пока что ссылка выглядит так, потому что общедоступная папка на самом деле переходит в корень, как только мы создаем проект:
"iconUrl": "https://markokhman.github.io/first_contract_front_end/icon.png"
Итак, вот наш новый файл манифеста:
{
"url": "https://join.toncompany.org",
"name": "TON&Co. Tutorial",
"iconUrl": "https://markokhman.github.jo/first_contract_front_end/icon.png" }
Теперь мы отправимся в файл main.tsx и составим здесь правильный URL-адрес:
Const manifestUrl = "https://markokhman.github.io/first_contract_front_end/tonconnect-manifest.json"
Последнее, что нам нужно сделать сейчас, это подготовить себя, чтобы построить для нас должным образом. Как вы можете видеть здесь, конфигурация vite имеет базу:
// https://vitejs.dev/config/
export default defineConfig({
plugins: [react (), nodePolyfills()],
base: "/",
});
Эта база не будет корневой, потому что у нас есть другая база: first_contract_front_end в моем случае. Это правила GitHub: имя репозитория должно быть базовым путем. Итак, давайте поставим это в качестве основы нашего проекта:
// https://vitejs.dev/config/
export default defineConfig({
plugins: [react (), nodePolyfills()],
base: "/first_contract_front_end/",
});
Создание рабочего процесса GitHub
На данный момент мы хорошо разбираемся в нашем существующем коде, но есть еще одна вещь, которую нам нужно сделать. Прежде всего, давайте побежим
yarn build
Это создает сервируемые файлы, которые исполняются в браузере, со всеми нашими TypeScript и прочим. Очевидно, что он не может работать прямо в браузере, поэтому нам нужно его построить. В папке dist у нас есть index.html со всеми подходящими путями, здесь у нас есть все файлы, вроде как в комплекте.
Но мы не хотим создавать yarn каждый раз, когда мы вносим некоторые изменения в репозиторий. Содержимое папки dist даже "gitignored". В GitHub ветвь репозитория считается ветвью, которая содержит содержимое веб-сайта на страницах GitHub. Потенциально мы можем просто создать ветку, в которой есть только содержимое папки, которая нам нужна, и эта ветка будет подключена непосредственно к URL-адресу, который мы только что описали.
Мы можем оптимизировать его, поэтому каждый раз, когда вы отправляете какие-либо изменения с локальной машины на GitHub, они будут подготовлены автоматически, поэтому страницы GitHub будут создаваться автоматически и включать в себя все текущее содержимое папки dist. Для этого у GitHub есть еще одна классная вещь — workflows.
Теперь мы создадим рабочий процесс, который будет делать работу за нас каждый раз, когда мы подталкиваем к репозиторию. В корневой папке нашего проекта мы создаем новый репозиторий под названием .github. Внутри него мы создаем другую папку под названием рабочие процессы. Это стандартные имена, поэтому вы не можете их изменить. В папке рабочих процессов мы создаем файл с именем deploy с расширением *.yml. Там я вставляю этот код:
Этот рабочий процесс под названием deploy будет срабатывать при любом толчках, который происходит в главной ветке. А потом мы начинаем определять рабочие места. У него есть две работы: сборка и развертывание. Вам не нужно ничего устанавливать, это просто терминология GitHub для конфигурации, синтаксиса.
В сборке мы указываем среду, в которой он работает. Вы должны проверить репозиторий, настроить узел для среды выполнения и версию узла, которая вам нужна. Тогда вы можете что-то установить. Конечным результатом будет dist папки сборки, как и у нас локально.
Следующее задание - развертывание. Здесь мы предоставляем информацию о том, как мы должны загружать артефакты этой папки dist и развертывать их на страницах GitHub. Для развертывания создается новая ветка GitHub Pages.
Мы сохраняем этот файл. Как вы помните, мы уже совершили это. Мы проверяем статус git с помощью команды git status и видим, что один файл был обновлен - vite.config.ts. Затем мы проверяем манифест: переходим к tonconnect-manifest.json, добавляем все с помощью команды git add . и фиксируем это с помощью git commit.
Наконец, мы переходим к папке .gitignore, проверяем, что общедоступная папка не игнорируется, и фиксируем ее в качестве рабочего процесса:
git commit -m "Workflow"
Отлично, у нас этот рабочий процесс готов! Давайте перейдем к настройкам нашего репозитория GitHub, Actions > General, и убедимся, что разрешения рабочего процесса установлены на "чтение и запись"; в противном случае мы не сможем создать папку.
Pushing the code
Следующий шаг - продвигать то, что мы совершили. Вернитесь в .gitignore и используйте команду:
Git push origin master
Зайдите на вкладку "Действия" в репозитории GitHub и посмотрите, как работает рабочий процесс. Обновить при необходимости:
Результатом этого рабочего процесса станет новая ветка под названием gh-pages. Каждый раз, когда мы продвигаем что-то в основное, этот рабочий процесс будет запускаться и обновлять эту новую ветку, фактически воссоздав ее, чтобы она имела последнюю сборку после завершения задания развертывания.
Теперь в ветвях мы можем увидеть новую ветку gh-pages с новым развертыванием. Перейти к Settings > Pages and in the Build and Deployment section choose gh-pages branch.
Вердитесь к действиям. Там вы увидите, что выполняется еще одно действие - это то, что будет развернуть нашу папку dist в нашем поддомене. Давайте посмотрим, что происходит внутри:
Тестирование страницы GitHub
После завершения этого процесса перейдите в Настройки > Страницы, и в верхней части вы увидите ссылку на наш веб-сайт. Мы заходим на этот сайт и видим, как он работает так же, как на нашей местной машине.
Давайте проверим это. Нажмите Connect Wallet, выберите Wallet > Tonkeeper и отсканируйте QR-код. Когда мы обновляли файл манифеста, мы видим значок и имя. Поскольку кошелек подключен, мы видим наш сайт со всеми кнопками действий.
Я нажимаю Increment by five и вижу, что все это происходит в домене. Сейчас это опубликованное производственное приложение. Я подтверждаю транзакцию своим кошельком. Как только данные блокчейна будут обновлены, мы увидим 10 в качестве значения счетчика. И баланс нашего контракта также увеличился, потому что я потратил немного денег на доставку этой транзакции.
Заключение
Мы только что развернули наше первое приложение для производства. Это работает одинаково для тестовой сети и основной сети. Это зависит только от вас, какие учетные данные и код вы хотите туда перенести. К этому моменту вы создали веб-приложение, которое работает публично для людей. Довольно хороший прогресс, которого мы достигли в последних нескольких главах!
Итак, прежде чем я объявлю вам, что мы будем делать на следующих уроках, позвольте мне отдать кредиты Orbs Команда, а именно Шахар Якир и Таль Коль - эти ребята подготовили много материалов, которые я использовал, изучая эту вещь, прежде чем объяснить ее вам. И я использовал некоторые из их материалов при подготовке этих уроков для вас. Так что я действительно хочу дать им кредиты и похвалы. Вы можете найти ссылки на их проекты в материалах этого урока, и я был бы очень признателен, если бы вы пошли и проверили это. TON Access, Библиотека, которую мы использовали на этих уроках, также была сделана командой Orbs, поэтому я действительно рекомендую вам проверить их продукты, потому что это самые крутые инструменты для разработки, которые вы можете найти.
Наконец, позвольте мне немного побаловать следующую главу. Там мы узнаем, как встроить интерфейс, который мы только что встроили, прямо в Telegram с его веб-приложениями. Я уверен, что тебе понравится. Еще одна вещь, которую мы собираемся сделать в следующей главе, это создать интерфейс чат-бота вместо веб-стиля. Чат-бот будет взаимодействовать с вашим пользователем, чтобы он мог что-то сделать с кошельком. Вы изучите эту концепцию и поймете разницу между интерфейсом чат-бота и веб-интерфейсом, который мы только что видели.
Я с нетерпением жду следующей главы, где мы собираемся расширить наши знания на новые горизонты. Оставайтесь с нами!
