Просто обожаю технические задачи в вакууме на собеседованиях. Ваше идеальное решение не проходит даже базовую проверку на предотвращение рефетча (откройте консоль, и увидите как запрос выполняется дважды при первом маунте).
Меня всегда поражала подобная самоуверенность интервьюеров.
Пишу комментарий спустя время, после прочтения статьи, и хотел сказать спасибо автору. И вроде уже тертый калач - но все время узнаю про новые крутые инструменты, без которых больше не могу жить.
PS: И на M1, и на Intel - зачасту, приходится проверять, включен ли Orbstack, перед запуском контейнера - вот на столько он не грузит систему.
Использование ключей вместо inline-сообщений сильно ухудшает DX. Разработка и сопровождение приложения с тысячами ключей становится кошмаром.
Поддержка ICU Message Format
Реализация ICU в i18next сложная и громоздкая. Добавление сообщений с этим форматом через ключи превращается в непрозрачный процесс. Библиотеки, такие как Lingui.js, предоставляют из коробки удобный API для работы с ICU.
Lazy loading в i18next
Lazy loading переводов в i18next через namespaces, но это решение крайне ограниченное. Если на странице внезапно потребуется другой namespace, он не будет загружен автоматически.
Lingui.js как альтернатива
• Lingui.js позволяет автоматическую экстракцию сообщений из компонентов, что устраняет необходимость ручного управления ключами.
• Если нужно - сообщения попадают в lazy-словари на основе вложенности компонентов
• API значительно проще: каррированные функции или компонент `` c натуральными сообщениями вместо громоздких ключей.
• Генерация переводов в формате gettext и ICU Message Format, что упрощает интеграцию с любыми системами управления для переводами.
Организация ключей
Придумывать и поддерживать ключи — это когнитивная нагрузка, которой легко избежать. Беспокоитесь о коллизиях текстов - контекст (context) решает эту проблему.
Я не встречал ничего более неудобного для фронта, чем gRPC. Удачи писать моки на классах, и дебаг бинарных данных во вкладке Network браузера. OpenAPI - наше всё!
Всё-таки скорость запуска тестов имеет значение, поэтому вместо Playwright я бы заменил на MSW. Также, вместо Express я бы использовал что-то на вроде Hono, но это скорее зависи от целей задачи.
Круто, решение в облаке здесь напрашивается само собой. Возможно, кому-то вполне может подойти кейс, где вы на сервер отправляете чистый поток, а обратно получаете дипфейк-видео. Без простой упаковки будет непросто найти рынок.
Было бы здорово привести альтернативные генераторы и принцип их работы.
Например, openapi-fetch использует тонкий клиент, и глубокое вычисление типов из результата генерации openapi-typescript (.d.ts-файл) для создания полноценного API-клиента со строгой типизацией.
Схожую идею я реализую в своем генераторе React-хуков для Tanstack Query - openapi-qraft.
А за статью - спасибо. По работе с OpenAPI на frontend, мне кажется, довольно мало статей.
У React - понятное и удобное управление состоянием, без лишней магии. Почему-то подавляющему большинству React-сообщества встроенные хуки нравятся. Вероятно, вы считаете, что это неудобно, и все вокруг ошибаются. Но, что, если ошибаетесь вы и просто плывете против течения впустую?
Работаю на одной работе по 7 часов в день, получаю миллион, а головняков вроде бы меньше.
На всякий случай отмечу, что TanStack роутер умеет кешировать результат лоадеров из коробки.
Просто обожаю технические задачи в вакууме на собеседованиях. Ваше идеальное решение не проходит даже базовую проверку на предотвращение рефетча (откройте консоль, и увидите как запрос выполняется дважды при первом маунте).
Меня всегда поражала подобная самоуверенность интервьюеров.
Пожалуй, вы забыли про пару важных моментов: Abort Controller и React Strict Mode.
Пишу комментарий спустя время, после прочтения статьи, и хотел сказать спасибо автору. И вроде уже тертый калач - но все время узнаю про новые крутые инструменты, без которых больше не могу жить.
PS: И на M1, и на Intel - зачасту, приходится проверять, включен ли Orbstack, перед запуском контейнера - вот на столько он не грузит систему.
Ключи для локализации
Использование ключей вместо inline-сообщений сильно ухудшает DX. Разработка и сопровождение приложения с тысячами ключей становится кошмаром.
Поддержка ICU Message Format
Реализация ICU в
i18nextсложная и громоздкая. Добавление сообщений с этим форматом через ключи превращается в непрозрачный процесс. Библиотеки, такие как Lingui.js, предоставляют из коробки удобный API для работы с ICU.Lazy loading в i18next
Lazy loading переводов в
i18nextчерез namespaces, но это решение крайне ограниченное. Если на странице внезапно потребуется другой namespace, он не будет загружен автоматически.Lingui.js как альтернатива
• Lingui.js позволяет автоматическую экстракцию сообщений из компонентов, что устраняет необходимость ручного управления ключами.
• Если нужно - сообщения попадают в lazy-словари на основе вложенности компонентов
• API значительно проще: каррированные функции или компонент `` c натуральными сообщениями вместо громоздких ключей.
• Генерация переводов в формате
gettextи ICU Message Format, что упрощает интеграцию с любыми системами управления для переводами.Организация ключей
Придумывать и поддерживать ключи — это когнитивная нагрузка, которой легко избежать. Беспокоитесь о коллизиях текстов - контекст (
context) решает эту проблему.Не выбирайте i18-next для новых проектов, пожалуйста, это самое отсталое решение.
Если вы просто тестируете типы, то подход ясный. Но если тестируете типы на данных, то обычного
satisfiesбудет достаточно для большинства случаев.Судя по описанию релиза все так. Крошечная директива, решающая кучу проблем.
Ну да, вот я сейчас пришел к своим бэкам и они взяли мне такие и затащили. Изначально нужно было что-то такое использовать - это верно.
Я не встречал ничего более неудобного для фронта, чем gRPC. Удачи писать моки на классах, и дебаг бинарных данных во вкладке Network браузера. OpenAPI - наше всё!
Хабр - это русскоязычная площадка, а не российская - в другой части мира тоже люди живут.
Всё-таки скорость запуска тестов имеет значение, поэтому вместо Playwright я бы заменил на MSW. Также, вместо Express я бы использовал что-то на вроде Hono, но это скорее зависи от целей задачи.
Наверное автор хотел раскрыть вопрос, как это можно сделать самому.
Лучше мигрировать.
Круто, решение в облаке здесь напрашивается само собой. Возможно, кому-то вполне может подойти кейс, где вы на сервер отправляете чистый поток, а обратно получаете дипфейк-видео. Без простой упаковки будет непросто найти рынок.
Git filter branch считается устаревшим(не развивается) и не рекомендуется к использованию. Рекомендуеися использовать git filter repo.
Было бы здорово привести альтернативные генераторы и принцип их работы.
Например, openapi-fetch использует тонкий клиент, и глубокое вычисление типов из результата генерации openapi-typescript (
.d.ts-файл) для создания полноценного API-клиента со строгой типизацией.Схожую идею я реализую в своем генераторе React-хуков для Tanstack Query - openapi-qraft.
А за статью - спасибо. По работе с OpenAPI на frontend, мне кажется, довольно мало статей.
Это уже больше подходит на секту.
У React - понятное и удобное управление состоянием, без лишней магии. Почему-то подавляющему большинству React-сообщества встроенные хуки нравятся. Вероятно, вы считаете, что это неудобно, и все вокруг ошибаются. Но, что, если ошибаетесь вы и просто плывете против течения впустую?