Pull to refresh
15
0.1

Пользователь

Send message

Было бы здорово привести альтернативные генераторы и принцип их работы.

Например, 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% случаев, когда запрос завершается успешно

В удобном приложении уведомления прилетают в реальном времени

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

По-вашему, сделать для пользователя удобное приложение - это кривое решение? Либо за вашей несуразной критикой скрывается нежелание решать реальные бизнес-кейсы, либо полное их непонимание.

Хорошо, перефразирую: разве вам не приходилось решать проблемы, которые вы процитировали?

И что из указанного вы считаете плохим/ненужным поведением?

Если через 5 лет вы еще останетесь во frontend - разработке, придите, и перечитайте свой комментарий.

 и хендлингом кеша!

Шта???) Вы о чём вообще?)

Именно так. Недостаточно просто получить данные, и надеяться, что этого достаточно.

  • Что будет, если 2 компонента вызовут fetch?

  • Что будет, если компонент часто монтируется? Каждый раз дергать fetch?

  • Как выполнять оптимистичное обновления стейта (например при сабмите формы) и отменять его при ошибке запроса?

  • Как инвалидировать данные, если пользователь долго не меняет стейт приложения (долго держит вкладку открытой)?

  • Как делать повторную попытку запроса, если произошла ошибка?

  • Как обрабатывать ошибки? А как обрабатывать ошибки при инвалидации данных?

  • Как отменять запрос (`AbortController`), если компонент размонтировался, или просто хочется сделать это глобально?

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

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

Такая ламповая статья, узнаю себя лет этак 10 назад. Хороший пример правильного использования backbone.

Удачи с дебагом и хендлингом кеша! Ваш код выглядит великолепно, и эффективно!

Да, подловил он меня в пылу, что тут скажешь.

Но я к $mol отношусь нормально. Не вижу проблем в инструменте, который решает проблему и приносит деньги. Совсем другой вопрос в другом - стоит ли продолжать инвестировать собственное время в инструмент, который так и не получил широкого распространения.

Пожалуй, для новых проектов сейчас идет выбор следующего порядка: HTMX или React/NG/Vue. В этом ряду нет ни Svelte, ни Solid и прочих крутых быстрых фреймворков. Когда действительно нужна скорость и легковесность, то лучше сразу делать на HTMX. Компании с приличной экспертизой не выберут промежуточное решение - либо полный хардкор, либо классический SPA на понятном стеке с миллионами разработчиков на рыке.

Я имел ввиду action из Remix. Next.js решает аналогичную задачу иным путем - через onSubmit. Обработка форм через action позволит стандартизировать хендлинг форм и на клиенте, и на сервере.

Information

Rating
3,087-th
Location
Нижний Тагил, Свердловская обл., Россия
Date of birth
Registered
Activity