Всё-таки скорость запуска тестов имеет значение, поэтому вместо Playwright я бы заменил на MSW. Также, вместо Express я бы использовал что-то на вроде Hono, но это скорее зависи от целей задачи.
Круто, решение в облаке здесь напрашивается само собой. Возможно, кому-то вполне может подойти кейс, где вы на сервер отправляете чистый поток, а обратно получаете дипфейк-видео. Без простой упаковки будет непросто найти рынок.
Было бы здорово привести альтернативные генераторы и принцип их работы.
Например, openapi-fetch использует тонкий клиент, и глубокое вычисление типов из результата генерации openapi-typescript (.d.ts-файл) для создания полноценного API-клиента со строгой типизацией.
Схожую идею я реализую в своем генераторе React-хуков для Tanstack Query - openapi-qraft.
А за статью - спасибо. По работе с OpenAPI на frontend, мне кажется, довольно мало статей.
У React - понятное и удобное управление состоянием, без лишней магии. Почему-то подавляющему большинству React-сообщества встроенные хуки нравятся. Вероятно, вы считаете, что это неудобно, и все вокруг ошибаются. Но, что, если ошибаетесь вы и просто плывете против течения впустую?
Давайте я сразу пропущу и ваши доводы, и ваш ужасный код - все это смехотворно.
Но вот на чем я действительно хотел бы заострить ваше внимание, так это на том, что у вас какая-то боязнь писать код специфичный для того фреймворка, с которым работаете. Вы привели пример совершенно нормального, чистого хука на SWR, и если это вызывает у вас старых, то, пожалуй, мы бы с вами не сработались.
Понимаю, что здесь уже сложно держать один вектор дискуссии. Изначально, мы говорили о MobX. Затем перешли к получению данных на примере кода комментатора выше.
Вы действительно можете использовать возможности Tanstack в том числе для MobX. Чего я не понимаю совершенно, так это для чего в современном проекте на React нужен MobX.
Так вроде бы тихая революция уже произошла, и победит HTMX. Пока для него недостаточно тулинга, привычного для frontend-разработчиков. Но, кажется, скоро не останется самих frontend-разработчиков, если HTMX получит широкое распространение.
На HTMX уже сегодня переводит свои старые сайты большой бизнес. By design HTMX предполагает серверный рендеринг в обычный plain html. Оказалось, что даже старенький WordPress можно сделать таким, что он не будет уступать React по базовым требованиям к SPA.
Веб-сокеты сложны сами по себе, и далеко не каждый backend будет заниматься реализацией их реализацией. Обычно, все что у вас есть - REST API / GraphQL.
В случае же, если вы действительно решили использовать сокеты, то без CRDT - это просто баловство.
Я где-то сказал, что вы пороха не нюхали? Я лишь отметил, что наши собственные желания бизнес не интересует.
Если в проекте, куда ты пришел, уже все написано на React, то, пожалуй, приходится мириться с этим, и думать о том, как улучшить хотя бы инкрементально, но не переписывать все на новый модный фреймворк.
Фундаментально! В следующий раз, когда мне будут в очередной раз говорить, какая классная и простая технология WS - я буду знать куда отправлять за весёлым чтением.
Не могли бы вы прояснить про SSE: если требуется установка соединения 1 раз, при условии что токен живёт долго, разве недостаточно передать токен при установке соединения через обычные куки?
А если предметно - эта дискуссия не имеет смысла. Вы - энтузиаст, продвигающий собственной решение, что похвально, но делаете это в довольно токсичной форме. А я отвечаю за использование инструментов для приложения, срок поддержки которого минимум 10 лет.
Так что весь разговор будет сводиться примерно к "я конечно все понимаю, но кто ваши мэинтейнеры?"
Вы либо намеренно "сужаете рамки", либо, как я сказал, не понимаете критериев.
В удобном приложении компоненты не ремонтируются
Это неправда. Я могу закрыть, а потом снова открыть карточку товара. Если это происходит за короткий промежуток времени, я бы не хотел видеть спиннер каждый раз, когда открываю карточку, которую только что закрыл.
В удобном приложении показывается реальное состояние, а не враньё про сделанную работу с откатами состояний
Это не так. Если вы используете websockets, для лучшей отзывчивости интерфейса вы должны использовать оптимистичные апдейты, иначе вы заставляете пользователя ждать в 99.9% случаев, когда запрос завершается успешно
В удобном приложении уведомления прилетают в реальном времени
Вы говорите о дизайне приложения, где сервер может присылать уведомления на клиент о том, что состояние изменилось. Во-первых, на уведомления сервера никогда нельзя полагаться. Во-вторых, это никак не устраняет проблемы инвалидации кеширования, так как событие с сервера также приходит с задержкой, и на актуальность его данных полагаться нельзя.
По-вашему, сделать для пользователя удобное приложение - это кривое решение? Либо за вашей несуразной критикой скрывается нежелание решать реальные бизнес-кейсы, либо полное их непонимание.
Всё-таки скорость запуска тестов имеет значение, поэтому вместо 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-сообщества встроенные хуки нравятся. Вероятно, вы считаете, что это неудобно, и все вокруг ошибаются. Но, что, если ошибаетесь вы и просто плывете против течения впустую?
Давайте я сразу пропущу и ваши доводы, и ваш ужасный код - все это смехотворно.
Но вот на чем я действительно хотел бы заострить ваше внимание, так это на том, что у вас какая-то боязнь писать код специфичный для того фреймворка, с которым работаете. Вы привели пример совершенно нормального, чистого хука на SWR, и если это вызывает у вас старых, то, пожалуй, мы бы с вами не сработались.
Понимаю, что здесь уже сложно держать один вектор дискуссии. Изначально, мы говорили о MobX. Затем перешли к получению данных на примере кода комментатора выше.
Вы действительно можете использовать возможности Tanstack в том числе для MobX. Чего я не понимаю совершенно, так это для чего в современном проекте на React нужен MobX.
Так вроде бы тихая революция уже произошла, и победит HTMX. Пока для него недостаточно тулинга, привычного для frontend-разработчиков. Но, кажется, скоро не останется самих frontend-разработчиков, если HTMX получит широкое распространение.
На HTMX уже сегодня переводит свои старые сайты большой бизнес. By design HTMX предполагает серверный рендеринг в обычный plain html. Оказалось, что даже старенький WordPress можно сделать таким, что он не будет уступать React по базовым требованиям к SPA.
Основные трудности с WS начинаются тогда, когда у вас несколько серверов, а также сложно управлять балансировкой. Аутентификация - тоже непросто.
С WS, как с обычным POST/GET, не получится побыстрому поднять лямбду, выполнить запрос и выключить ее.
Если вы действительно пошли в WS, ваша команда должна точно понимать, какие цели они преследуют, и достаточна ли квалификация разработчиков.
Веб-сокеты сложны сами по себе, и далеко не каждый backend будет заниматься реализацией их реализацией. Обычно, все что у вас есть - REST API / GraphQL.
В случае же, если вы действительно решили использовать сокеты, то без CRDT - это просто баловство.
Я где-то сказал, что вы пороха не нюхали? Я лишь отметил, что наши собственные желания бизнес не интересует.
Если в проекте, куда ты пришел, уже все написано на React, то, пожалуй, приходится мириться с этим, и думать о том, как улучшить хотя бы инкрементально, но не переписывать все на новый модный фреймворк.
Фундаментально! В следующий раз, когда мне будут в очередной раз говорить, какая классная и простая технология WS - я буду знать куда отправлять за весёлым чтением.
Не могли бы вы прояснить про SSE: если требуется установка соединения 1 раз, при условии что токен живёт долго, разве недостаточно передать токен при установке соединения через обычные куки?
А если предметно - эта дискуссия не имеет смысла. Вы - энтузиаст, продвигающий собственной решение, что похвально, но делаете это в довольно токсичной форме. А я отвечаю за использование инструментов для приложения, срок поддержки которого минимум 10 лет.
Так что весь разговор будет сводиться примерно к "я конечно все понимаю, но кто ваши мэинтейнеры?"
Вы либо намеренно "сужаете рамки", либо, как я сказал, не понимаете критериев.
Это неправда. Я могу закрыть, а потом снова открыть карточку товара. Если это происходит за короткий промежуток времени, я бы не хотел видеть спиннер каждый раз, когда открываю карточку, которую только что закрыл.
Это не так. Если вы используете websockets, для лучшей отзывчивости интерфейса вы должны использовать оптимистичные апдейты, иначе вы заставляете пользователя ждать в 99.9% случаев, когда запрос завершается успешно
Вы говорите о дизайне приложения, где сервер может присылать уведомления на клиент о том, что состояние изменилось. Во-первых, на уведомления сервера никогда нельзя полагаться. Во-вторых, это никак не устраняет проблемы инвалидации кеширования, так как событие с сервера также приходит с задержкой, и на актуальность его данных полагаться нельзя.
По-вашему, сделать для пользователя удобное приложение - это кривое решение? Либо за вашей несуразной критикой скрывается нежелание решать реальные бизнес-кейсы, либо полное их непонимание.
Хорошо, перефразирую: разве вам не приходилось решать проблемы, которые вы процитировали?
И что из указанного вы считаете плохим/ненужным поведением?