ReactJS *

Чек-лист для эффективного технического интервью

1. Подготовка: что сделать перед собеседованием

• Определите 3 главных навыка, необходимых для вакансии. Например: «Оптимизация React», «Работа с легаси-кодом (React классы)», «Работа с Redux».

• Подготовьте реальные задачи из вашего проекта, а не абстрактные алгоритмы.

• Четко опишите стек технологий и проблемы проекта, чтобы кандидат понимал контекст.

Пример: «У нас проект на React 16.8. Остались классовые компоненты, которые нужно переписать на хуки, и мы используем классический Redux».

2. Структура собеседования

А. Вводная часть (5-10 минут)

• Представьтесь и расскажите о проекте простым и понятным языком.

• Спросите кандидата, есть ли у него опыт работы над подобными задачами.

Б. Проверка навыков (30-50 минут)

1. Практическая задача (5-10 минут)

   • Дайте кандидату упрощенную версию реальной проблемы. Например: «Нужно переписать классовый компонент на хуки и подключить его к Redux, а затем оптимизировать рендер».

   • Позвольте кандидату воспользоваться интернетом для поиска информации. Главное, чтобы он показал процесс решения задачи, а не просто копировал ответ.

2. Гибкие вопросы (5-10 минут)

   • В процессе выполнения задачи или после ее завершения (на мой взгляд, лучше после) задавайте вопросы, которые помогут вам лучше понять подход кандидата.

   Пример: «Вы использовали кеширование. Расскажите подробнее, как это поможет нашему проекту?»

3. Финальное обсуждение задачи (10-15 минут)

   • Обсудите решение задачи целиком, что получилось, а что можно улучшить.

4. Если все навыки не уместились в одну задачу, вернитесь к шагу 1.

В. Заключение (5-10 минут)

• Дайте кандидату возможность задать вопросы о проекте.

• Объясните, какие будут следующие шаги, чтобы не оставлять его в подвешенном состоянии.

3. Критерии оценки

Оценивайте кандидата по конкретным показателям, а не по субъективным впечатлениям:

1. Понимание проблемы — видит ли кандидат суть задачи?

2. Процесс решения — как ищет ответ, какие вопросы задает?

3. Качество кода — читаемость, оптимизация.

4. Коммуникация — может ли кандидат объяснить свои решения?

Пример оценки:

• ✅ «Правильно переписал с классов на хуки и подключил Redux» — отличный кандидат!

• ⚠️ «Правильно настроил кеширование, но забыл useCallback в одном месте» — нужно обсудить детали.

• ❌ «Не смог объяснить, почему компонент ререндерится» — потенциальные риски для проекта.

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

Реакт уже никогда в жизни не догонит angular по производительности и функциональности) Рано или поздно от реакта откажутся, потому что библиотека всегда будет уступать полноценному фреймворку. Жду коммы от джунов, которые в жизни не работали с крупными проектами

SOLID как священная корова? 🤔
Я думал, что пост о «фальшивых сеньорах» пройдёт спокойно — ну, очередной крик души о собеседованиях. 😅 Но нет! Хабровчане увидели слово «SOLID» и решили, что это вызов их святыне. Хотя я ничего плохого про него не сказал — просто отметил, что в React 2025 спрашивают про него по инерции. 😕

Где магия, а где фарс? ✨
Комментатор с саркастичным «быдлокод» (спасибо за реакцию, коллега!) будто подтвердил мою мысль: SOLID — это не религия, а инструмент. 🛠
SRP (Single Responsibility) в React — это о компонентах. Но если ваш «компонент формы» содержит логику, стили, валидацию и даже полёт на Марс, это не нарушение SOLID’а, а просто плохой код. 🌙
DIP (Dependency Inversion) в мире хуков и Context API чаще выглядит как «передать пропс» или «создать useClient», чем как «абстрактный фабричный фасад». 🧩
LSP (Liskov Substitution) в функциональном программировании? Его там просто нет. Или вы верите, что Button и IconButton должны наследоваться от AbstractClickable? 🤔

Если кандидат не может объяснить даже это, а только бормочет о «SOLID — это про ответственность» и использует ChatGPT, это не про принципы, а про некомпетентность. 🙅‍♂️

Про GPT и кандидатов-попугаев 🦜
«Чатжпт вам расскажет» — именно! Но если человек не может пересказать своими словами, он не понимает. А если не понимает, как он будет применять это на практике? 😵

Вывод 📜
SOLID — это хорошо. Плохо — догматично использовать его без понимания, где он нужен, а где создаёт лишние сложности. 🚫

🤡 «Фальшивые сеньоры»: как меня пытались обмануть кандидаты

Кандидат с «идеальной памятью»

Сидит передо мной разработчик. Отвечает на вопросы... странно:

Простые вещи вроде «что такое замыкание» — щёлкает как орешки.

Сложные вопросы — делает паузу на 15 секунд... и выдаёт академический ответ.

Решил проверить на практике:

✅ Теория — 10 из 10

❓ Практика — 6 из 10: простые и типовые задачи легко, рефакторинг с адской болью

❌ Объяснить, что и для чего делал — 0 из 10. Поддержать диалог, хоть как-то отойти от шаблонов — это всё не про таких кандидатов.

Напоминает студента, который выучил билеты, но не понимает предмет. Скорее всего, ему кто-то подсказывал, или он просто зазубрил типовые ответы.

«SOLID? Ну это когда ответственно»

Обычно я не люблю спрашивать про SOLID (кому вообще это нужно в React в 2025?). Но тут поведение кандидата было подозрительным — решил проверить.

Диалог:

— Расскажи про SOLID

— Это принцип единственной ответственности!

— Я жду продолжения

— Всё...

— Больше ничего не помнишь?

— Ну это основная часть....💥

Тут всё еще грустнее, видимо, GPT просто выкинул перед кандидатом 5 принципов без пояснения, что все 5 принципов образуют SOLID.

Так к чему это я:

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

Как провести идеально бесполезное собеседование для фронтендера!

Шаг 1: Берем «элитный» шаблон Яндекс.Мультитрека.

Шаг 2: Удаляем всё ценное — оставляем только хаотичный набор вопросов.

Шаг 3: Делаем вид, что это «специально под вакансию» (спойлер: одни и те же 40 вопросов получают все — от стажера до лида).

Главные хиты программы:

— «Назови 5+ способов центрировать div» (ведь React-лид должен уметь это с закрытыми глазами). — «Расскажи про Event Loop как стихотворение» (иначе как проверить лидерские качества?). — «SOLID наизусть, включая историю создания каждого принципа». — Секретный прием: задаем общие вопросы, но с видом эксперта ждем «правильного» ответа (который знает только интервьюер).

Философский бонус: пока такие собеседования существуют, «прохождение собеседований» остаётся отдельным навыком в вакууме — где побеждает не тот, кто лучше код пишет, а тот, кто научился угадывать, что имел в виду интервьюер.

Гарантированный результат:

• Кандидат либо засыпает, либо пишет гневный пост.

• Ваша компания экономит на зарплатах — никто не доходит до оффера.

• Вы получаете статус «самое запоминающееся собеседование в карьере». Если узнали свою компанию — не переживайте, вы не одиноки в этом увлекательном квесте!

Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки

Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос «Почему Gravity тормозит?»

Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.

Методология исследования

Технический стек:

• Playwright — фреймворк для автоматизации тестирования кода в разных браузерах (подробнее).

• PerformanceObserver API — браузерный API для измерения производительности (подробнее).

Условия выполнения тестов:

• Каждый тест запускается в отдельном контексте браузера.

• Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.

• Каждый тест повторяется 50 раз.

• Тесты проводятся с разным количеством нод (10, 100, 1000).

Порядок выполнения одного теста:

1. Открытие новой страницы в браузере.

2. Инициализация PerformanceObserver.

3. Начало сбора метрик.

4. Рендеринг компонентов.

5. Завершение сбора метрик.

Процесс измерения:

В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.

Результаты

Результаты замеров не содержат в себе абсолютных цифр. От окружения к окружению они, конечно же, могут варьироваться. Но этих цифр вполне достаточно, чтобы увидеть некоторые зависимости и сделать на их основании выводы:

1. @gravity‑ui/uikit показывает конкурентоспособные результаты:

   • В большинстве тестов находится в верхней части рейтинга.

   • Демонстрирует стабильное время рендеринга при разном количестве нод.

   • Особенно эффективен в компонентах Button, Checkbox и Switch.

   • Имеет проблемы со временем рендера компонента TextArea.

2. @mui/material также показывает хорошие результаты:

   • Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.

   • Имеет видимый рост времени рендера в зависимости от количества нод.

3. antd и React Spectrum:

   • Показывают более высокое время рендеринга в большинстве тестов.

   • Имеют больший разброс между минимальным и максимальным временем.

С помощью этого инструмента можно провести замеры производительности на своей локальной машине, а также добавить тесты для компонентов, которых ещё нет. Нам поможет, если вы развернёте его у себя и пришлёте в PR результат работы на своём компьютере.

В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!

Всем привет. В свободное время создаю игру, хотел привлечь студентов для реальной практики, которую студенту без опыта получить практически нереально (опробовал на себе лет 10 назад), знал что есть такое место как GB, но и тут облом, оказывается раздел уже не актуален, где можно было бы разместить информацию о своем проекте, и привлечь молодую кровь, жаждущих практики на реальных проектах.

Но где сейчас обитает студент? Где можно рассказать о себе, и закинуть удочку для поиска интернов? Хотелось бы и собрать команду, и дать молодым специалистам возможность пополнить свое портфолио реальным кейсом. Заранее спасибо.

Как тестировать фронтенд?

Для меня уже нет вопроса - нужны ли тесты на фронтенде? Личный опыт подсказал, что нужны, как и согласованный цельный подход к архитектуре. Тому есть несколько причин:

• Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.

• Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.

• У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.

• Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.

Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.

• Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.

• А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.

• Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).

А какие практики для тестирования применяете вы?

Опубликовано исследование о том что индексирование сайтов поисковиком (Google) не зависит от того, SPA ли это или же он SSR. Также пару лет назад делал аналогичное расследование и пришел к тому же выводу.

Вообще, мы пришли к идеалу достаточно давно - когда сервер занимается своими делами, а клиент статический, минифицирован, и раздается из CDN для быстроты и без траты ресурсов сервера.

https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process

Стоит ли идти во фронтенд сейчас? Честный ответ разработчика

Артем несколько лет в сфере (вот его история). Сейчас он разработчик в крупном финтех-проекте. Вот его мысли:

— Да, фронтенд перенасыщен. Фреймворков много, технологии постоянно меняются. Все говорят об одном, но пишут по-разному. Но именно это и держит в тонусе — приходится регулярно обновлять знания. Сожалею ли я о своем выборе? Нет. Всегда любил погружаться в математические задачи, а фронтенд затягивает. Можно сутки биться над багом, ненавидеть его, плеваться… А потом решить — и словить кайф. В такие моменты код полностью поглощает, заставляя забыть о сне и еде.

Стоит ли идти во фронтенд сейчас?

— Никогда не поздно. Да, путь у каждого свой, и рынок сейчас нестабилен. Но при глубоком погружении за год можно набрать нужные скиллы и попасть на коммерческий проект.

🔥 Открыт набор на новый марафон!

Сейчас в Clevertec проходит марафон для начинающих фронтенд‑разработчиков. Это возможность погрузиться в профессию, получить реальный опыт и, возможно, стать частью команды. Участие бесплатное. Успей зарегистрироваться!

Запускаем бесплатный онлайн-марафон по фронтенд-разработке. Будет как в «Рокки» 

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

Как записаться?

Заполни анкету по ссылке в профиле и скинь другу. Заявки принимаем до 26 марта.

Что будет?

Интенсивный 3-месячный тренинг. Это бесплатно. По сути, ты будешь поэтапно с дедлайнами писать приложение. Каждый спринт проверяем с помощью автотестов. Плюс будет поддержка менторов, наших крепких разработчиков. Это реальная прокачка твоих навыков и готовый проект в резюме.

Это уже четвертый марафон — после каждого наша команда фронтенд-разработчиков растет.

Кого ждём?

Начинающих веб-разработчиков (JS, React), которые уже изучали теорию и хотят прокачаться на практике в условиях, максимально близких к реальному проекту. Главное — желание кодить. Подойдут:

- студенты профильных вузов

- выпускники курсов

- самоучки

Важное условие: приглашаем участников из Беларуси и России.

Что дальше?

После 26 марта отправим на почту инструкции и первые задания. Старт марафона 1 апреля (это не шутка). До связи, Рокки. 

Как мы сокращали количество запросов по фичам в API

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

Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID

За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.

Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.

Примерно вот так:

GET /users/user
// Response
{
  "tgUsername": ...,
  "tgId": ...,
  ...
}

GET /users/features/quizzes/completed
// Response
{
  "completedQuizzes": ...,
}
   
GET /users/features/pages/bought
// Response
{
  "boughtPages": ...,
}
   
GET /users/features/rates/rate
// Response
{
  "userRate": ...,
}

При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота

Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка

Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:

GET /app/account/data

// Response
{
  ...
  "user": ...,
  "completedQuizzes": ...,
  "boughtPages": ...,
  "currentRate": ...,
  ...
}

За одно перепроверили, что:

• не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);

• если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);

• берём общие часто запрашиваемые данные из кэшей.

Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.

---

Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.

flushSync в React – костыль или спасение?

Вчера впервые попробовал flushSyncб который подвезли в React еще в 18 версии.
Классное решение для определенных моментов! Выглядит так, будто React выдал нам костыль, но сразу предупредил: пользоваться с осторожностью.

❓ Почему это вообще нужно? (Для тех, кто не совсем в теме)
В React изменения в useState или в useEffect выглядят синхронными, но на самом деле они асинхронны.

Простой пример:

...

const [count, setCount] = useState(0);

console.log(count); // 0

setCount(1); console.log(count); // Всё ещё 0! 😲

...

Кажется, что setCount(1) сразу меняет count, но на самом деле новое значение попадёт в консоль только при следующем ререндере.

То же самое в useEffect:

...

useEffect(() => { console.log("Эффект сработал!"); }, [count]);

setCount(1); console.log("А это после setCount");

...

Лог "А это после setCount" появится в консоли раньше, чем "Эффект сработал!", потому что useEffect выполняется уже после рендера.

Как flushSync меняет поведение?

Обычно React группирует обновления (batching) и откладывает ререндер до конца текущего цикла. flushSync ломает это поведение и заставляет React сразу выполнить ререндер.

function Example() { 
    const [count, setCount] = React.useState(0); 
    const ref = React.useRef(null);
    const handleClick = () => { 
        flushSync(() => setCount(count + 1)); 
        console.log("Высота элемента:", 
            ref.current?.offsetHeight); 
        };

    return (<button onClick={handleClick}>
        Добавить  {count}
    </button>); 
} 

Что тут происходит?
Без flushSync React подождал бы до конца текущего вызова и только потом обновил DOM.
С flushSync обновление происходит немедленно, и console.log видит уже новый DOM.

React нас предупреждает
В документации прямо сказано:

"flushSync – это низкоуровневый API. Используйте его только тогда, когда вам действительно нужно измерить DOM сразу после обновления состояния."

Когда не стоит использовать flushSync?
Если можно обойтись обычными useEffect или useLayoutEffect.
Если batching работает нормально и не мешает.
Если нет необходимости немедленного ререндера (иначе можно уронить производительность).

Итог
flushSync – мощный инструмент, но использовать его нужно осознанно. Он нужен в случаях, когда важно немедленно обновить стейт и тут же прочитать DOM (например, для анимаций).

Если понравился пост присоединяйтесь к моему каналу в Telegram по ссылке https://t.me/+qbK9ZPuAocI2MWUy.
Там я делюсь своим опытом и пишу материалы которые будут полезны как новичкам, так и матерым разработчикам.

Выводим Ситника на чистую воду

Топ перлов:

• Sync-engine избавляет от однотипного кода по загрузке данных .. он заставляет вас проверять isLoading === true и рисовать крутилку.

• Во всех sync-engine используются нормальные стейт менеджеры .. например, nanostore (см. видео с разбором этой библиотеки).

• (Я запилил штуку, которая ничего не умеет, но ты можешь поверх этой штуки запилить своих костылей для решения проблем, которые у тебя возникнут из-за моей штуки).

• CRDT - это просто лог операций (лог операций - это CmRDT и OT, CvRDT даже близко не лог).

• Работать с IndexedDB через скомпилированный под WASM SQLite быстрее, чем напрямую работать с IndexedDB (разве что, если руки заточены под обнимашки).

Упомянутые ссылки:

• Local-First база данных CRUS-DB

• Децентрализованное хранилище секретов

• Реактивный ToDoMVC без sync-engine

• $mol_wire в React

• Протоколы запросов HARP vs GQL

• Легковесный язык разметки MarkedText

• Натальная травматология фронтенда

• Гильдия Гипер Дев

Копилка благодарностей

Доклад с SPb IT Club Meetup №3
Фреймворк, который нельзя называть

Исследовал интернет и наткнулся на GitHub Unwrapped. Он на основе активности в GitHub создаёт видео, где можно увидеть часто используемые языки, часы спонтанной работы, звёзды и всё остальное. Достаточно ввести только имя профиля, чтобы получить видео. Код открыт.

Сделано с использованием Remotion — тоже с открытым кодом, которая позволяет автоматизировать создание видео на React в веб. Документация хорошая, но надо разбираться. Увидел это и решил, что круто, надо поделиться!

P.S. Моя активность в этом ролике, если кому-то будет интересно.

Fusor для React резработчиков за 5 минут

Репозиторий: https://github.com/fusorjs/dom

Мы подготовили гайд по настройке автогенерации с помощью Orval. Он облегчит жизнь разработчиков, которым часто не хватает времени на оптимизацию и рефакторинг приложений. Весь процесс описан пошагово, код и ссылки на библиотеки вы также найдете в статье https://habr.com/ru/articles/848182/

Привет друзья! Сделал максимально простые аналоговые часы на SVG. Можно ли их еще упростить или уменьшить? Или добавить немного улучшений без переусложнения? Буду рад вашим идеям!

Вот CodeSandbox

Сделано с помощью библиотеки Fusor

Как в нативе: эти Web API поднимут ваше веб-приложение в стратосферу

Салют, на связи Clevertec. Сейчас наша команда разрабатывает веб-версию банкинга с использованием React. С помощью Web API даем пользователям фичи, которые они привыкли получать в нативных приложениях. Отрываем от сердца список решений 😉

- Web Share API – для обмена ссылками, текстом и файлами с другими приложениями на устройстве. К примеру, удобно отправить чек об оплате в мессенджере, не покидая банковское приложение. 

- Contact Picker API позволяет делиться контактами из своего списка. Можно использовать для перевода по номеру телефона. Не нужно вводить цифры вручную – поле автоматически заполнится контактом из телефонной книги. 

- Media Capture and Streams API в нашем случае позволяет отсканировать QR-код с помощью камеры устройства. Нажимаешь на “Сканировать QR” – открывается окно с камерой, она считывает код и переводит пользователя в дерево платежей.

- Web OTP API открывает возможность автоматически вставлять код из смс. Например, для подтверждения оплаты на телефон приходит сообщение. Внизу экрана появляется модальное окно с подтверждением вставки. И после нажатия на “Разрешить” код отображается в поле ввода.

Подробнее про этот опыт использования Web API мы рассказали в отдельной статье. Что вы думаете о Web API, какие используете? Расскажите в комментариях, будем взаимно полезны друг другу.