Web Share API: делаем нативную кнопку «Поделиться» с fallback

Пользователи всё чаще ожидают, что поделиться контентом с сайта можно через нативный диалог операционной системы — как в мобильных приложениях. Вместо громоздких блоков с десятком кнопок соцсетей достаточно одной кнопки «Поделиться», которая вызывает системный интерфейс: Telegram, WhatsApp, Notes, AirDrop и другие приложения. Web Share API — встроенная возможность браузера — даёт это без установки сторонних SDK. Мы уже реализовали такой шаринг для 15+ проектов, и он стабильно работает на iOS и Android. Наш опыт в нативных API — более 5 лет, и мы гарантируем корректную работу на всех поддерживаемых браузерах.

Однако у API есть особенности. На десктопах поддержка неполная: в Firefox и Safari macOS нативный диалог не открывается. Поэтому критически важно предусмотреть fallback — копирование ссылки в буфер обмена. В этой статье разберём, как правильно интегрировать Web Share API с учётом всех нюансов: проверка поддержки, шаринг файлов, обработка ошибок и React-компонент с запасным вариантом.

Почему Web Share API лучше кастомных кнопок?

Кастомные кнопки соцсетей требуют интеграции отдельного SDK для каждой платформы, обновления при изменениях API и не дают нативного UX. Web Share API решает всё одной функцией:

API встроено в браузер, не требует загрузки скриптов и работает даже офлайн (если страница загружена).

Что такое Web Share API и как он работает?

Web Share API — это встроенный метод браузера navigator.share(). Вы передаёте объект с полями title, text, url или files, и браузер открывает системный диалог выбора приложений. Согласно спецификации MDN, API поддерживается на iOS Safari 12.1+, Android Chrome 61+, Edge 79+. На десктопных Chrome и Edge (Windows) API работает, Firefox и Safari macOS — нет.

Какие данные можно шарить через Web Share API?

API позволяет шарить:

• Текст и URL (обязательно хотя бы одно)
• Файлы: изображения, PDF, видео — через свойство files
• Данные с Canvas после конвертации в Blob

Для проверки поддерживаемого типа данных используйте navigator.canShare(). Если данные не поддерживаются, выбросится ошибка — её нужно перехватить и выполнить fallback.

Базовый шаринг

interface ShareData {
  title?: string
  text?: string
  url?: string
  files?: File[]
}

async function share(data: ShareData): Promise<void> {
  if (!navigator.share) {
    throw new Error('Web Share API не поддерживается')
  }

  // Проверка, что браузер поддерживает конкретный набор данных
  if (!navigator.canShare(data)) {
    throw new Error('Этот тип контента не поддерживается для шаринга')
  }

  await navigator.share(data)
}

Эта утилита — база для любой интеграции. Обрати внимание: canShare необязателен, но без него ошибка может возникнуть только во время вызова.

Шаринг файлов

async function shareFile(file: File, title?: string): Promise<void> {
  const data: ShareData = { files: [file], title }

  if (!navigator.canShare?.(data)) {
    // Fallback: предложить скачать файл
    const url = URL.createObjectURL(file)
    const a = document.createElement('a')
    a.href = url
    a.download = file.name
    a.click()
    URL.revokeObjectURL(url)
    return
  }

  await navigator.share(data)
}

// Шаринг Canvas как изображения
async function shareCanvas(
  canvas: HTMLCanvasElement,
  filename: string,
  title?: string
): Promise<void> {
  const blob = await new Promise<Blob>((resolve, reject) =>
    canvas.toBlob((b) => (b ? resolve(b) : reject(new Error('Ошибка'))), 'image/png')
  )
  const file = new File([blob], filename, { type: 'image/png' })
  await shareFile(file, title)
}

React-компонент с fallback

interface ShareButtonProps {
  url: string
  title?: string
  text?: string
  fallbackCopy?: boolean
}

function ShareButton({ url, title, text, fallbackCopy = true }: ShareButtonProps) {
  const [copied, setCopied] = useState(false)
  const supportsShare = typeof navigator !== 'undefined' && 'share' in navigator

  const handleShare = async () => {
    if (supportsShare) {
      try {
        await navigator.share({ url, title, text })
      } catch (e) {
        // Пользователь отменил — не считается ошибкой
        if (e instanceof Error && e.name !== 'AbortError') {
          console.error('Share error:', e)
        }
      }
      return
    }

    if (fallbackCopy) {
      await navigator.clipboard?.writeText(url)
      setCopied(true)
      setTimeout(() => setCopied(false), 2000)
    }
  }

  return (
    <button onClick={handleShare}>
      {supportsShare ? 'Поделиться' : copied ? 'Ссылка скопирована' : 'Копировать ссылку'}
    </button>
  )
}

Как обработать ошибки при шаринге?

Основная ошибка — AbortError, когда пользователь закрывает диалог. Её следует игнорировать. Другие ошибки (например, неподдерживаемый тип данных) нужно логировать и, при необходимости, показывать fallback. В нашем компоненте мы уже обработали AbortError, а остальные ошибки логируем. Если API недоступно, компонент автоматически переключается на копирование ссылки.

Когда использовать fallback для копирования?

Fallback обязателен на всех десктопных браузерах, кроме Chrome и Edge (Windows). Даже на мобильных устройствах некоторые старые версии iOS не поддерживают API — для них также нужен fallback. Мы реализуем автоматическое определение поддержки: если navigator.share не существует, копируем URL в буфер обмена через navigator.clipboard.writeText().

Процесс работы над интеграцией под ключ

Мы предлагаем готовое решение «под ключ» за 2–4 часа. Процесс включает:

1. Анализ требований и аудит текущей архитектуры шаринга.
2. Проектирование: выбор стратегии fallback, определение поддерживаемых данных (текст, URL, файлы).
3. Реализация утилиты share с проверками и обработкой ошибок.
4. Интеграция React-компонента (или компонента для другой библиотеки — Vue, Angular).
5. Тестирование на реальных устройствах: мобильные (iOS, Android), десктопные браузеры (Chrome, Firefox, Edge, Safari).
6. Деплой и мониторинг ошибок.

Сроки: от 2 до 4 часов в зависимости от сложности (поддержка файлов, кастомный UI). Свяжитесь с нами, чтобы оценить ваш проект и получить консультацию по интеграции Web Share API. Мы гарантируем корректную работу на всех поддерживаемых браузерах и документируем код.

Что входит в работу

Утилита share с проверкой поддержки и canShare, React-компонент с fallback (копирование в буфер), поддержка файлов и изображений при необходимости, обработка AbortError (пользователь закрыл диалог).

Срок: 2–3 часа.

Закажите интеграцию нативного шаринга через Web Share API — сэкономьте до 95% времени на разработку кастомных кнопок. Получите консультацию наших инженеров.

Фронтенд-разработка 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 страниц.

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