Валерий Баранов — React Query в деле: как Яндекс Командировки уже три года живут без state-менеджера

• Приветствие участников эфира.  

• Представление Валеры Баранова, который расскажет о том, как Яндекс.Командировки живут без стейт-менеджера уже три года.  

• Вопрос о том, почему решили отказаться от стейт-менеджера.  

• Проект начался с использования Redux, но столкнулся с проблемами из-за большого количества бойлерплейта.  

• Решение использовать концепцию серверных данных и отказаться от стейт-менеджера.  

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

• Валера рассказывает о своем опыте работы в Яндексе и руководстве фронтендом Яндекс.Командировок.  

• Описание интерфейса сервиса и его функций.  

• Упоминание о стеке технологий: React, TypeScript, статический сайт на Next.js.  

• Объяснение, что данные в приложении можно представить как функцию от состояния.  

• Описание структуры данных: конфиг, роутер, мета, профиль.  

• Конфиг и роутер доступны синхронно, мета и профиль - асинхронно.  

• Проблемы с использованием Redux для работы с серверными данными.  

• Описание процесса получения данных о командировках.  

• Решение использовать React Query для работы с серверными данными без стейт-менеджера.  

• Валера рассказывает о стратегиях кеширования и работе с серверными данными в Яндекс.Командировках.  

• Упоминание о специфике использования хуков React Query через обертки.  

• Подведение итогов и выводы.  

• Автор просит задавать вопросы в чате, если что-то не понятно.  

• Время доклада ограничено, и он не смог охватить все аспекты темы.  

• Возможность дискуссии после доклада.  

• Пример компонента, рендерящего информацию о командировке.  

• Использование хука useQuery из React Query.  

• Запрос данных из бэкенда и хранение их в кэше.  

• Кэширование данных в React Query.  

• Стратегия stale-while для предотвращения лишних рендеров.  

• Таймер для очистки кэша и проверка актуальности данных.  

• Настройки stale-time и cache-time.  

• stale-time определяет, как долго данные считаются свежими.  

• cache-time определяет, как долго данные хранятся в кэше.  

• Две основные стратегии: stale-while и cache-first.  

• Stale-while используется для данных, которые могут быстро измениться.  

• Cache-first используется для данных, которые вряд ли изменятся.  

• Примеры данных, использующих стратегию stale-while.  

• Примеры данных, использующих стратегию cache-first.  

• Настройки для каждой стратегии в зависимости от типа данных.  

• Использование веб-сокетов для получения актуальных данных в реальном времени.  

• Стратегия кэш-он-ли: использование React Query как кэша для глобальных данных и офлайн-режима.  

• Методы set и get для работы с кэшем.  

• Использование хуков useEffect для мутирующих запросов.  

• Инвалидация данных при изменении и автоматическая перезагрузка страницы.  

• Пример работы с оберткой для динамических и зависимых запросов.  

• Использование опции disable для предотвращения автоматических запросов.  

• Пример динамических запросов в зависимости от типа услуги.  

• Зависимые запросы: запуск второго запроса только после получения данных первого.  

• Запросы, зависящие от состояния булевой переменной.  

• Пример с командировками: загрузка данных участников в зависимости от типа командировки.  

• Реализация предзагрузки данных для мобилки.  

• Использование метода для предзагрузки данных при инициализации приложения.  

• Пример с активными командировками: данные обновляются при переключении вкладок.  

• Использование оптимистичного обновления для бинарных действий.  

• Важность быстрого отклика и высокой успешности выполнения операций.  

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

• Оптимистичное обновление усложняет разработку и ухудшает опыт разработчиков.  

• В командировках не используется, так как это может быть чувствительной информацией.  

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

• Используется концепция ремонт дата с библиотекой дата тс.  

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

• Компонент ремоут используется для рендеринга данных в зависимости от статуса.  

• Бэк-энд возвращает спецификацию в формате оп-напи.  

• Используется кастомный код генератор для создания опишки.  

• Обертки для хуков, таких как ю-стрипс, используются для работы с данными.  

• Хук ю-стрипс используется для получения данных в формате дата.  

• Обертка над юквери возвращает данные в формате дата и обеспечивает декларативную инвалидацию данных.  

• Данные роутера используются только на уровне страниц, что обеспечивает безопасность и безопасность использования данных.  

• Используются тесты юниты и трибуки.  

• Для тестов используется моксерверкеры и мок-опишка.  

• Реакторов туз используется редко, так как флоу-данных в приложении предсказуем и декларативен.  

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

• Пользователи оценили улучшение производительности и кэширования данных.  

• Приложение получает высокие оценки от пользователей.  

• В проекте нет бойлерплейта, используются сложные обертки.  

• Хуки описываются декларативно, что позволяет легко отслеживать изменения данных.  

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

• Если не уверены, нужен ли стейт-менеджер, попробуйте начать без него.  

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

• По QR-коду можно попасть в телеграм-канал автора для вопросов и дискуссий.  

• Автор готов ответить на вопросы и подискутировать о серверных данных.  

• Быстрые действия могут сбивать с толку, что автор осознал только сейчас.  

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