Web3-фронтенд: передача проекта и восстановление операций
Оглавление курса «Web3-интерфейс: реестр в браузере» · Урок 30 из 30.
В конце курса соберём карту интерфейса учебной библиотеки. Она нужна, чтобы другой разработчик мог продолжить проект и понять, где находится источник каждого состояния. Результат — список модулей, явные переходы операции и план восстановления. Это архитектурная передача подготовленного примера, а не отчёт о выполненном развёртывании.
Мы сохранили базовый CourseCatalog: неизменяемый издатель, текущие записи, публикация и деактивация. Сеть лаборатории31337, Solidity0.8.30/Cancun и viem2.37.9 остаются закреплённым профилем. React-линия использует React19.1.1, wagmi2.16.9 и TanStack Query5.85.5 отдельно от современной миграции v3. Учебные программы, кошелёк, транзакции, тесты и установка зависимостей не выполнялись.
От страницы до сети
Конфигурация определяет экземпляр и поколение лаборатории. Публичный клиент проверяет сеть и читает состояние. ABI связывает методы с байтами. Модуль снимка сохраняет блок и его хеш. Карточка переводит нормализованные данные в безопасный текст. Эти элементы образуют путь чтения, который не требует подключения аккаунта.
Отдельный путь записи начинается с выбора провайдера. Пользователь разрешает доступ к аккаунту, а приложение проверяет сеть и издательские полномочия. Форма создаёт намерение с точными аргументами. Симуляция возвращает запрос для конкретного контекста. Кнопка подписи сверяет этот контекст и передаёт действие кошельку. После хеша начинается независимое наблюдение.
Receipt определяет факт включения и исход исполнения. Повторное чтение показывает текущее состояние, которое может отличаться от результата более ранней операции. Журнал сохраняет заменённые попытки и неизвестность при тайм-ауте. Так интерфейс не сводит всю последовательность к одному булеву success.
Карта модулей
| Область | Ответственность | Что она не доказывает |
|---|---|---|
| Deployment | Сеть, адрес и поколение экземпляра | Качество материалов издателя |
| Public Client | Чтение RPC выбранного окружения | Честность произвольного endpoint |
| Snapshot | Происхождение нескольких значений | Неизменность всех будущих блоков |
| Manifest digest | Связь байтов с объявленным отпечатком | Доступность файла и правильность текста |
| Wallet context | Аккаунт, сеть и поколение подготовки | Серверную сессию читателя |
| Simulation | Ожидаемое исполнение в наблюдаемом состоянии | Гарантированный будущий успех |
| Operation journal | Намерение, хеши и факты наблюдения | Полную резервную копию проекта |
Таблица помогает не передавать одной части лишние обязанности. Например, модуль рендеринга не выбирает RPC, а кеш не решает полномочия издателя. Если новая функция заставляет компонент одновременно хранить ключ, проверять подпись и рисовать курс, стоит пересмотреть границы раньше, чем добавлять ещё одно условие.
Состояния пользовательского маршрута
Подготовка начинается с черновика. После проверки аргументов появляется намерение. Успешная симуляция создаёт подготовленный запрос. Ожидание кошелька является самостоятельным этапом. Отказ возвращает человека к форме, а получение хеша переводит действие в отправленное состояние. Наблюдение завершается receipt или сохраняет неизвестность при временном отказе.
Смена аккаунта, сети, экземпляра или аргументов инвалидирует подготовку. Она не стирает уже отправленную транзакцию. Удаление компонента прекращает его подписки и применение поздних ответов, но не отменяет сетевое исполнение. Повторное открытие страницы возобновляет чтение журнала без автоматической подписи.
Эта модель применима не только к publish. Для deactivate меняются аргументы и ожидаемый эффект, а этапы согласия и наблюдения остаются. Однако семантика метода сохраняется явно: деактивация текущей записи не удаляет отпечаток и не гарантирует отзыв скачанного файла. Общий контроллер не должен спрятать различие действий за слишком универсальной кнопкой.
Что передать следующему разработчику
Рядом с исходниками сохраняются версия ABI, запись развёртывания, параметры компилятора и правило хеширования манифеста. Версии библиотек фиксируются в файле зависимостей и будущем lockfile после отдельной установки. Здесь не создаём выдуманный lockfile и не утверждаем, что пакеты действительно установлены.
Для каждого подготовленного листинга обозначается, является ли он полным модулем или фрагментом расширения. Такой статус полезен при сборке учебного проекта: разработчик видит, откуда приходят publicClient, catalogAbi и функции нормализации. Markdown-курс содержит последовательность исходников, но не заменяет автоматически готовый проверенный архив приложения.
В передаче отдельно перечисляются непроверенные части: доступность локального RPC в браузере, поддержка выбранного провайдера, поведение дополнительных коннекторов, сборка React-линии и реальные ответы кошелька. Их нельзя считать выполненными только потому, что текст описывает ожидаемый результат. Пользовательский запрет запусков соблюдён во всех шагах.
План самостоятельного осмотра
Когда будет разрешён запуск, начинают с чтения без кошелька. Затем рассматривают отсутствующую запись, недоступный узел и неправильную сеть. После этого проверяют явное подключение, отказ и смену аккаунта. Только затем переходят к симуляции, подписи и receipt. Такой порядок позволяет отделить обычные веб-ошибки от сетевых действий.
Дополнительные сценарии включают поздний ответ старого запроса, замену транзакции, тайм-аут после хеша, перезагрузку и две вкладки. Для каждого заранее задан ожидаемый статус. Наличие списка не означает, что проверки уже выполнены; это карта будущего подтверждения поведения и поиска расхождений с текстом.
Доступность рассматривается через всю последовательность: клавиатура, сообщения этапов, отказ кошелька и восстановление. Полный адрес и отпечаток доступны для копирования, а цвета не являются единственным обозначением результата. Новые события не переставляют фокус и не стирают пользовательский черновик.
Следующие расширения
Для каталога с большим числом курсов браузерная история заменяется индексатором с checkpoint и обработкой реорганизации. Серверный кабинет требует отдельной подписи входа, nonce и сессии. Контрактные аккаунты добавляют свои правила проверки подписи и исполнения. Эти задачи развивает курс входа и индексирования.
Публикация материалов по содержимому и независимое хранение развиваются в курсе IPFS. L2 и оракулы добавляют новые этапы доверия, но не отменяют базовое правило: наблюдение, намерение, подпись и фактическое исполнение остаются разными состояниями. Перед расширением нужно назвать, какие сведения появились и какой участник отвечает за них.
Итоговое упражнение — объяснить путь одного выпуска курса17 другому разработчику без слова «магия» и без общей фразы «кошелёк всё сделает». Назовите источник каждого значения, момент согласия и маршрут восстановления после сбоя. Если это получается, архитектура стала понятной основой дальнейшей работы. Первичные API доступны в документации viem и EIP-1193.