React Native *

Представьте: вы создали приложение, которое работает ровно тогда, когда у пользователя есть интернет. Нет интернета? Поздравляю, у вас мёртвое приложение и куча недовольных пользователей. Ну или курьер, который стоит как дурак и не может выполнять свою работу, потому что приложение зависло. Бизнес стоит, а вы сидите и ждёте, что всё само решится (нет).

Если хотите перестать выглядеть полными профанами и дать юзерам что-то, что не падает при первом же обрыве связи — welcome to local-first apps. Здесь всё про то, чтобы сделать локальную базу, а синхронизация — это такая себе приятная бонусная функция, а не священный грааль.

Если ты в 2025 году ты всё ещё руками собираешь авторизацию на Laravel для своей админки — у меня для тебя плохие новости. Ты либо получаешь удовольствие от страданий, либо просто не знаешь про Admiral. А хорошие новости заключается в том, что это open source фреймворк, который не позволяет не сойти с ума копипаста и рутинной хрени. Вместо этого он делает всё за тебя (что? да!). Ты просто поставишь, настроишь пару штук — и вуаля: авторизация, фронт, работающий бекенд.

В этом гайде я покажу, как без боли и слёз запустить связку Laravel + Admiral с полной авторизацией. Ни строчки лишнего кода, и ни минуты на сомнительные патчи.

Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.

Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).

Как мы в Купере переписали CodePush для React Native. Быстрее, легче, удобнее

Всем привет! Меня зовут Евгений Прокопьев, я разработчик на React Native с 9-летним стажем. В этой статье расскажу, как мы в Купере написали собственный CodePush, который совсем не похож на продукт Microsoft.

React Native не справился. Flutter — как глоток свежего воздуха.

Рассказываем, как наша команда переписала большое приложение (60+ экранов, оффлайн режим, карта, камера) на Flutter, с чем пришлось повозиться и почему теперь не жалеем.

Всех приветствую. Сегодня хочу с вами поделиться и разобрать малоизвестную, но очень сильную технологию взаимодействия двух приложений на одном устройстве.

Представьте, что в Вашем Android-приложении, нужно взаимодействовать с другим приложением на том же устройстве — например, приложение для видеоконференций, умный дом, видеоплеер, пульт управления и прочие приложения. Тут уже зависит от Вашей смекалки. Вы хотите, чтобы эти приложения общались плавно, безопасно и эффективно. Что приходит первое в голову? Скорее всего ответ будет броадкаст или контент провайдер. Но что если нужно обрабатывать информацию в реальном времени и отвечать тут и сейчас, или к примеру нужно общаться между двумя приложениями?

В 2022-м мы окончательно задолбались.

Каждый новый проект все по кругу: таблички, формы, фильтры, CRUD. Всё снова, как в Groundhog Day. Копипастить старое было больно, собирать с нуля – ещё хуже. И главное, ощущение абсурда: 2022 год, а мы продолжаем лепить админки вручную, будто на дворе 2015.

Окей, логичный шаг – найти готовое решение.

Мы правда пытались не изобретать велосипед

Первым делом пошли смотреть на CMS. Попробовали Strapi – мощный зверь, но если вам просто нужно бэку выдать пару CRUD’ов, то тянуть за собой целую экосистему с философией и особым образом жизни, это как стрелять из базуки по воробьям.

Дальше, дизайн-системы вроде Salesforce Lightning, Fluent UI и Fusion Design. Компоненты красивые, но по факту это просто UI-кирпичики. Всю бизнес-логику, связи между сущностями, обработку данных всё равно пишешь сам. Хотели сэкономить время, а получили “ты теперь ещё и архитектурой займись”.

React-Admin показался перспективным. Но мы быстро поняли, что он хочет, чтобы ты делал вещи его способом. А мы хотели делать их по-своему. Онбординг тяжёлый, кастомизация сложная, UI на любителя. Как часто бывает: сначала кажется, что ты взял инструмент, а потом он берёт тебя.

Мы поняли: компромиссы – это медленно

Меня зовут Алексей Цуцоев, я разработчик мобильных приложений в KODE, и я хочу поделиться историей того, как мы внедряли игру в уже готовое React-Native приложение. Как выбирали технологию, с какими трудностями столкнулись и к каким выводам пришли.

Привет, с вами снова я – Дмитрий, React-разработчик, хотелось бы сегодня затронуть тему среды выполнения JS. Многие знают, другие уже подзабыли, а новички — вовсе не в курсе. В общем, эта статья точно найдёт своих читателей. Постараюсь простыми словами и по делу.

Недавно я получил неожиданное письмо от Google, после которого пришлось срочно писать криптоприложение. Спойлер: там пончики. Много пончиков.

Если ты пишешь на React Native, но устал от его ограничений (типа NFC, Bluetooth или системных фич), эта статья — твой выход. Мы разберём ключевые аспекты разработки нативных модулей для React Native приложений.

Что внутри:
Зачем это надо — когда JS бессилен, а нативный код спешит на помощь.
Как написать свой модуль** — от наследования до обработки системных плюшек (на примере работы с уведомлениями).
Фишки интеграции — куда складывать готовый код, как регистрировать и вызывать из JS.
Готовый пример — бери и используй (или переделывай под свои нужды).

Для кого:
Для тех, кто уже дружит с RN и Kotlin/Java, но хочет больше власти над устройством.

Что получишь:
Рабочий код (не просто "Hello, World!"),
Четкие шаги без воды,
Понимание, как лезть в другие системные штуки.

Итог:
Нативные модули — это мощный инструмент, который делает ваш гибридный код по-настоящему нативным. Хочешь больше, чем предлагает фреймворк? Допиливаешь сам. Статья покажет как.

Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно. Мы называем это “джаваскрипт”, но под капотом скрываются три разные сущности: EcmaScript, среда исполнения и экосистема. Иногда о них стоит говорить отдельно, но сегодня я хочу обсудить всё сразу и объяснить, почему джаваскрипт — это плохой язык. Не в смысле “не работает”, а в смысле “заставляет страдать”.

Автор: разработчик и фаундер с опытом запуска стартапов в сферах туризма, HR tech, а сейчас — в музыкальной индустрии.

По образованию — Data Scientist, по призванию — Android-разработчик и продукт-менеджер.

Работал в крупных продуктах вроде X5 и Uzum, где впервые познакомился с Kotlin Multiplatform Mobile (KMM). Когда настал момент создавать прототип для своего музыкального стартапа, выбор был очевиден: я уже знал Kotlin, имел боевой опыт с KMM — и хотел быстро двигаться без лишних компромиссов.

Но KMM — не единственный путь.

На столе были и Flutter, и React Native, и даже классическая нативка.

В этой статье я расскажу:

Сегодня разберёмся, как сделать видеозвонки — ту самую фичу, без которой сложно представить современное общение в 2025 году, на примере реализации мессенджера.

Для этого мы познакомимся с WebRTC — технологией, которая позволяет приложениям устанавливать прямое соединение друг с другом для обмена аудио, видео и другими данными. Это мощный, но местами капризный инструмент, который требует понимания архитектуры, сигналинга и сетевых нюансов вроде NAT и ICE.

Это рецензия на русский перевод книги Fluent React: Build Fast, Performant, and Intuitive Web Applications автора Кумара Теджаса. Для тех разработчиков, кто следит за литературой по React, напомню, что в январе мы рецензировали на Хабре книгу по React 19 российского автора Виктора Дронова. Наверняка, будет интересно сравнить подходы авторов и набор тем, которые они освещают.

Подписки в GraphQL позволяют клиенту подписаться на изменения данных на сервере. Например, в чате с их помощью можно получать уведомления о сообщениях, их удалении или изменении. В отличие от обычных запросов, подписки работают асинхронно, поддерживая постоянное соединение через WebSocket. В этом случае сервер может в любое время послать запрос клиенту. В то же время для обычных запросов(queries), чтобы увидеть изменение данных, клиенту нужно запрашивать их заново каждый раз. А ещё с помощью GraphQL Subscriptions и библиотеки Relay можно создать собственный мессенджер.

История от задумки до запуска на Google Play приватного финансового менеджера inCourse для Android на React Native и TypeScript.

Создаем React Native проект на Expo 52 с Tamagui с нуля. В этой статье я поэтапно показываю что я сделал.

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

В этой статье вы поймёте как он устроен, зачем он нужен и на примерах научитесь его правильно применять.

Меня зовут Александр Чернов, я фронтенд-разработчик в KODE и я использую React Native в разработке мобильных приложений уже более семи лет. Сейчас расскажу вам, как мы у нативных разработчиков хлеб отбирали.