Веб-интерфейс минтинга NFT: смарт-контракты, Merkle Tree

Веб-интерфейс минтинга: от контракта до транзакции

Отметим: когда пользователь нажимает кнопку Mint, фронтенд связывается с контрактом через кошелёк. Ошибки вроде InsufficientFunds или InvalidMerkleProof пугают пользователей, а газовые войны в пике требуют быстрой обратной связи. Без правильной обработки транзакция может сгореть, обойдясь пользователю в $0.5 бесполезного газа. Мы строим интерфейс, который предсказуем: коннект кошелька, проверка условий (whitelist, лимиты, статус продажи), отправка транзакции с декодированием ошибок и финальный экран с токеном. Клиенты часто сталкиваются с неправильной проверкой whitelist-статуса или неверной ценой газа. Наше решение автоматически подбирает оптимальный gas price через viem и проверяет все условия перед отправкой. Наша команда имеет многолетний опыт в блокчейн-разработке — мы реализовали десятки NFT-проектов с интеграцией смарт-контрактов на Ethereum и EVM-совместимых сетях. Гарантируем чистый код на TypeScript с использованием актуальных библиотек wagmi и viem.

Подготовка смарт-контракта

Первый шаг — изучить ABI. Типичный контракт использует стандарт ERC-721A для эффективного batch-минта. Обязательные функции: mint, whitelistMint, totalSupply, maxSupply, mintPrice, maxPerWallet, saleState и numberMinted. Пример ABI с viem — читайте состояние контракта через multicall для одновременного получения всех данных:

// Типичные функции минт-контракта
function mint(uint256 quantity) external payable;
function whitelistMint(uint256 quantity, bytes32[] calldata proof) external payable;
function totalSupply() external view returns (uint256);
function maxSupply() external view returns (uint256);
function mintPrice() external view returns (uint256);
function maxPerWallet() external view returns (uint256);
function saleState() external view returns (uint8); // 0=paused, 1=whitelist, 2=public
function numberMinted(address owner) external view returns (uint256);

Для чтения состояния используем multicall — он позволяет за один RPC-запрос получить totalSupply, maxSupply, mintPrice, maxPerWallet, saleState и numberMinted для кошелька. Это снижает нагрузку на провайдер и ускоряет UI.

Почему Merkle Tree — стандарт для whitelist?

Хранение всех whitelist-адресов в контракте стоит газа при развёртывании. Merkle tree решает эту проблему: в контракте хранится только корень, а proof генерируется на фронтенде по адресу пользователя. Это в 10 раз дешевле по газу. Реализация на TypeScript с библиотекой merkletreejs:

// lib/merkle.ts
import { MerkleTree } from 'merkletreejs';
import { keccak256, encodePacked } from 'viem';

// allowlist.json — массив адресов из CMS или API
import allowlist from '@/data/allowlist.json';

function hashLeaf(address: string): `0x${string}` {
  return keccak256(encodePacked(['address'], [address as `0x${string}`]));
}

const leaves = allowlist.map(hashLeaf);
const tree = new MerkleTree(leaves, keccak256, { sortPairs: true });

export function getMerkleProof(address: string): `0x${string}`[] {
  const leaf = hashLeaf(address);
  return tree.getHexProof(leaf) as `0x${string}`[];
}

export function isWhitelisted(address: string): boolean {
  const leaf = hashLeaf(address);
  return tree.verify(tree.getHexProof(leaf), leaf, tree.getRoot());
}

Экономия на развертывании составляет 0.09 ETH — весомый аргумент для Merkle Tree. При среднем газе 20 Gwei это около $500 экономии на одном развертывании. Кроме того, каждая whitelist-проверка становится дешевле, что особенно заметно при большом количестве пользователей.

Какие шаги по интеграции интерфейса?

1. Проанализируйте ABI контракта: выделите все функции и события, необходимые для минта.
2. Спроектируйте структуру React-компонентов: MintWidget, StatusBar, ErrorDisplay, TransactionProgress.
3. Реализуйте хуки для чтения состояния с помощью useReadContract и useReadContracts из wagmi.
4. Добавьте логику отправки транзакций через useWriteContract и отслеживайте статус через useWaitForTransactionReceipt.
5. Интегрируйте Merkle Tree: сгенерируйте proof на фронтенде и передайте в контракт.
6. Протестируйте на тестнете, симулируйте все ошибки, задеплойте на продакшн.

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

Как обрабатывать ошибки минтинга?

Минтинг падает по многим причинам: недостаточно ETH, превышен лимит кошелька, продажа не активна, неверный proof. Ошибки из viem содержат ABI-декодированное сообщение контракта:

import { ContractFunctionRevertedError, UserRejectedRequestError } from 'viem';

function parseMintError(error: Error): string {
  if (error instanceof UserRejectedRequestError) {
    return 'Транзакция отклонена в кошельке';
  }
  if (error instanceof ContractFunctionRevertedError) {
    const reason = error.data?.errorName ?? error.message;
    const messages: Record<string, string> = {
      'ExceedsMaxPerWallet': 'Превышен лимит токенов на кошелёк',
      'SaleNotActive': 'Продажа ещё не начата',
      'InvalidMerkleProof': 'Ваш адрес не в вайтлисте',
      'InsufficientFunds': 'Недостаточно ETH',
      'MaxSupplyReached': 'Все токены заминтены',
    };
    return messages[reason] ?? `Ошибка контракта: ${reason}`;
  }
  return 'Неизвестная ошибка';
}

Тестирование и безопасность

Перед запуском мы проводим симуляцию всех состояний контракта с помощью Hardhat fork. Тестируем граничные случаи: когда maxSupply достигнут, когда кошелёк не имеет ETH, когда proof неверен. Используем принципы checks-effects-interactions для предотвращения reentrancy атак. Дополнительно настраиваем мониторинг через Etherscan API для отслеживания успешных и неудачных транзакций. Это гарантирует, что пользователь никогда не увидит непонятную ошибку, а газ не будет потрачен впустую.

Процесс работы и что входит

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

Сроки: базовая версия с публичным минтом и прогресс-баром — 2–3 дня. Полная реализация с whitelist, Merkle Tree и деплоем — 4–6 дней.

Закажите разработку интерфейса минтинга — свяжитесь с нами для оценки вашего проекта. Получите бесплатную консультацию и точный сметный расчёт.

Фронтенд-разработка React: от аудита до production

Бандл вырос до 3.1 MB gzip — это реальная цифра из проекта, который пришёл к нам на аудит. Причина: moment.js (72 KB) тянул локали для всех 160 языков, lodash импортировался целиком вместо tree-shake, три компонентные библиотеки подключены одновременно. TTFB отличный, но TTI (Time to Interactive) на мобильном — 14 секунд. Пользователи уходили, конверсия упала на 40%. Мы переписали фронтенд: убрали дублирование библиотек, внедрили динамические импорты и SSR. Результат — бандл уменьшился до 850 KB gzip, TTI — 2.1 секунды, LCP — 1.8 с.

Frontend — это не «нарисовать красиво». Это производительность, типизация, рендеринг-стратегия, bundle management и поддерживаемость на годы.

Почему Next.js — стандартный выбор для SEO?

React — наш основной UI-фреймворк для сложных интерфейсов. Next.js — стандартный выбор для проектов с SEO-требованиями или SSR. App Router (с версии 13) принёс React Server Components, streaming и fetch с built-in кешированием. Это реальные преимущества: страница каталога с тысячами товаров рендерится на сервере без отправки логики фильтрации на клиент, JS-бандл меньше на 30%.

Но App Router — другой способ мышления. "use client" нужно ставить осознанно. Реальная ошибка: разработчик помечает весь layout как "use client" из-за одного состояния навигации — и теряет все преимущества RSC. Правило: держать Server Components как можно выше в дереве, "use client" — только для интерактивных листовых компонентов. ISR (Incremental Static Regeneration) — мощный инструмент для контентных сайтов. На каталоге из 50 000 страниц с ISR и CDN — TTFB < 50 ms для любой страницы.

Как TypeScript предотвращает баги в продакшене?

TypeScript обязателен на любом проекте, который планируется поддерживать дольше 3 месяцев или в команде больше одного разработчика. Аргумент «пишем быстро без типов» работает только первые 2 недели. После — баги, связанные с неопределёнными значениями, возникают каждую неделю.

Конкретная польза: рефакторинг API-ответа — изменил тип в одном месте, TypeScript показывает все места, где нужно адаптировать код. Без типов — баг в продакшене через неделю. strict: true в tsconfig.json — обязательно. noImplicitAny, strictNullChecks, strictFunctionTypes. Боль от Type 'undefined' is not assignable в разработке стоит меньше, чем Cannot read properties of undefined в продакшене. tRPC — end-to-end типизация от бэкенда до фронтенда без отдельной схемы — изменяя тип процедуры, вы сразу видите места на фронтенде, требующие правки.

Vue 3 + Nuxt 3 — альтернативный стек для SSR

Vue 3 с Composition API — другой стиль разработки, ближе к React Hooks. <script setup> и composables делают код более переиспользуемым. Nuxt 3 — фреймворк для Vue с SSR/SSG, аналогичный Next.js. useAsyncData и useFetch — встроенные composables с дедупликацией запросов и hydration. Auto-imports удобны, но могут запутывать при debug. Nuxt Content — модуль для Markdown/MDX-файлов, идеален для документации.

Hydration mismatch — специфическая боль SSR на Vue и React. Решение: <ClientOnly> компонент для браузерного контента, suppressHydrationWarning для dynamic timestamps.

Производительность: метрики и инструменты

Bundle analysis — стартовая точка. @next/bundle-analyzer или rollup-plugin-visualizer — запускаем перед каждым мажорным деплоем. Цель: ни одна страница не должна требовать > 200 KB JS gzip для first paint.

Динамические импорты для тяжёлых компонентов:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типичные кандидаты на dynamic import. Без этого они попадают в основной бандл. React DevTools Profiler — для поиска лишних ре-рендеров. React.memo, useMemo, useCallback — точечные инструменты. Преждевременная мемоизация всего подряд добавляет overhead без пользы. Профилируйте сначала, оптимизируйте потом.

Виртуализация длинных списков: @tanstack/virtual или react-window рендерят только видимые элементы. Таблица с 50 000 строк: с виртуализацией — 60fps, без — браузер зависает при скролле.

State management: без оверинжиниринга

Для большинства приложений достаточно:

• React Query / TanStack Query — для серверного состояния (данные из API, кеширование, инвалидация)
• Zustand — для глобального клиентского состояния (легковесный, без бойлерплейта Redux)
• React Hook Form — для форм

Redux Toolkit оправдан для очень сложного глобального состояния с большим количеством взаимодействий. Для большинства задач — это overkill. Recoil, Jotai — атомарные подходы для независимых кусков состояния.

CSS и дизайн-система

Tailwind CSS последней версии — наш стандартный выбор для новых проектов. Utility-first, отличная интеграция с компонентными библиотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива когда нужна более явная изоляция стилей. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненты с полным контролем над стилями. Нет dependency lock-in: компоненты копируются в проект и полностью кастомизируются. Storybook — для документирования компонентной библиотеки. React DevTools Profiler — официальный инструмент от команды React.

Тестирование

E2E тесты через Playwright — для checkout, авторизации, критичных форм. Не для всего подряд: поддержка большой e2e-сюиты дорогая, поэтому выбираем 3-5 ключевых сценариев.

Ориентиры по срокам и состав работ

Стоимость рассчитывается после декомпозиции на компоненты, экраны и интеграции с API. Мы используем N+1 оценку: прибавляем 20% на риски.

Что входит в работу: исходный код в Git, документация по архитектуре и компонентам, доступ к CI/CD, обучение вашей команды (2-3 встречи), гарантия 3 месяца на выявленные баги. Дополнительно — покрытие юнит-тестами ключевых модулей.

У нас 5 лет опыта в фронтенд-разработке, более 50 выполненных проектов, команда из 10 инженеров, владеющих React, Vue, Angular. Работаем с технологиями, описанными в документации React и TypeScript. Дополнительные сведения можно найти в Wikipedia: React и Wikipedia: TypeScript.

Какой стек выбрать для фронтенд-разработки React?

Мы сравниваем инструменты по реальным метрикам. Next.js быстрее Nuxt в сборке SSR на 20–30% при одинаковом размере страницы. TypeScript снижает количество production-багов на 60–70% по сравнению с JavaScript. Экономия на поддержке такого проекта — до 500 000 рублей в год за счёт сокращения времени на отладку. Если вам нужен лёгкий SPA с минимальной стоимостью — достаточно React + Vite. Для контентного сайта с SEO — Next.js с ISR даёт TTFB ниже 50 мс даже при 50 000 страниц.

Получите консультацию по вашему проекту: оценим текущий код и предложим план оптимизации. Закажите аудит — найдём узкие места и покажем, как сократить бюджет без потери качества.