Ну так как же всё-таки с помощью react-query сделать несколько запросов с условиями внутри jsx-компонента?..) Например, как это переписать на react-query? Желательно красиво и в продакшн-реди стиле.. хочу посмотреть что выйдет.)

const MyComponent = () => {
    
    // - по сабмиту получаем данные из формы

    // - делаем три параллельных запроса, в каждом 
    // из которых свои данные формы

    // - по результату второго запроса - делаем или не делаем 
    // четвёртый запрос, в котором используем ответ первого запроса.

    // - если четвёртый запрос ок - показываем успех 
    // с данными из этого запроса-4

    const submitHandler = async (formData) => {
      const responses = await Promise.all([
        service1.fetchData(formData.fieldValue1),
        service2.fetchData(formData.fieldValue2),
        service3.fetchData(formData.fieldValue3),
      ]);
    
      if (responses[1].isExistSomeData) {
        const data = await service4.fetchData(responses[0]);
        service5.showSuccess(data);  
      } else {
        service5.showFailure();  
      }
    };

    return <SomeButton onClick={submitHandler}>click</SomeButton>
};

Я понимаю, что там очень богатое апи.. мутации, condition-query.. и т.д. поэтому и хочу увидеть как с помощью этой библиотеки обработать логику выше, при нажатии на кнопку в рамках какого-то jsx-компонента. Как это правильно делают люди??..)

Потому что по своему опыту - это делается ужасно.. и рекламируемый профит react-query/swr и подобных абсолютно не стоит того.. если даже нельзя описать обычную последовательность запросов сверху\вниз без всяких костылей. Вот и хочу сравнить.. скорее всего я просто не умею пользоваться.

Ну так а как реализовать логику submitHandler с помощью react-query?

Так useQuery - это ж хук.. разве он может быть внутри массива, или внутри функции submitHandler вообще?

Можете пожалуйста подсказать как закодировать такую логику:

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

На обычноим js это получается просто и понятно:

const submitHandler = async (formData) => {
  const responses = await Promise.all([
    service1.fetchData(formData.fieldValue1),
    service2.fetchData(formData.fieldValue2),
    service3.fetchData(formData.fieldValue3),
  ]);

  if (responses[1].isExistSomeData) {
    const data = await service4.fetchData(responses[0]);
    service5.showSuccess(data);  
  } else {
    service5.showFailure();  
  }
};

Как это будет выглядеть в jsx-компоненте с помощью react-query?)

Тесты по TDD обычно пишутся теми же, кто пишет код. Если разработчик неправильно истолковал требования - то и тест, и тестируемый модуль будут содержать ошибку.

Вот если бы тесты писали постановщики задач перед тем как передавать задачу в разработку!.)

Чтобы наверняка узнать на фронте, что контракт поменялся, а вам об этом не сообщили, нужно использовать проверку runtime-типов.

Я плавно подводил к этому)

Как вы считаете, если учесть что:
- фронт и бек пишут разные команды, может даже распределённые географически и во времени
- фронт и бек это разные репозитории
- факт согласования контракта\апи присутствует в любом случае, между лидами фронта\бека или с участием аналитика - неважно
- необходимость шага - оповещения фронт-команды про обновление контракта
- как следствие, необходимость шага - фронту "поправить код" (в рамках отдельной задачи, или в попыхах неважно)

Верно ли следующие, что:

Проще и надёжнее фронтам описывать контракт в своей кодовой базе и валидировать его в рантайме (условный zod делает это в одно "приседание"), и не доверять апи-респонсам также, как и не доверять пользовательскому вводу, поскольку это пограничные слои приложения. Да, будет некое дублирование кода во фронт\бек командах. Зато не будет дополнительного "непонятного\мусорного" кода 50-100кб на фронте. Да, не будет удобной(?) странички сваггера со всеми эндпоинтами, которую бек должен не забывать обновлять. Зато у фронта будет свой, написанный собственноручно контракт со всеми "ручками", а своему коду доверия больше как-то)) И самое главное, что при смене контракта - количество телодвижений остаётся ровно столько же, т.е. два - оповестить фронт, и поправить код фронта. И инструменты вроде swagger-typescript-api никакой рекламируемой автоматизации особо не добавляют (учитывая список моментов выше).

Почему я затеял эту дискусию.. потому что у меня часто подгорает когда на проектах 2+ года всеми любимый сваггер не соответствует действительности.. потому что это завязано на дисциплину бекенд-разработчиков. А фронт страдает.. че не работает?.. а блин Петя забыл аннотацию поправить и вообще сказать что он поменял поля этого ответа чуть-чуть))

Спасибо за ответы.

И да, когда контракт обновляется нужно клиент генерировать заново.

Вот тут не совсем ясен флоу. Был контракт, что возвращается поле user_messages. Потом бекенд-команда переименовала его на userMessages (примем, что они не забыли поменять аннотации в коде, или отредактировать в сваггер-эдиторе).

Факт смены поля.. об этом как-то сообщается, и если да - то в какой момент времени?.. например в слак "парни, мы поменяли поля - все пересоздайте у себя клиенты и поправьте маппинг!"

Или же оно должно дойти до qa или pipeline, там упасть, и только потом вернуться на фронт команду с отдельной задачей - чтоб те пересоздали клиенты и поправили маппинг?

Парочка вопросов:

1. Как описыватеся или генерируется сам контракт.. руками? swagger-editor? комментрии в роутах?

2. Если фронт и бек пишут разные люди - как фронт-команда узнаёт что контракт изменился и нужно пересоздать "клиент"?

Для меня вишенкой на торте стало внезапное понимание старых любимых песен.. типа слушал всю жизнь металлику и слушал.. и тут бац, понимаешь о чём песня.. невероятный кайф)

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

Я как разработчик - постоянно только этим и занимаюсь почему-то)) Иногда мечтаю побыть просто кодером..)

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

зачем в компонентах вызывать fetch? пусть себе компоненты (хоть сотня компонентов) рисуют данные, которые лежат в одном единственном месте.

Всё как обычно - нужно иметь чуйку, когда выделять из общего в частное, а когда обобщать частное в общее (не важно, функции, фронт, бек, инфраструктура, дизайн, бизнес, жизнь..). Также главное не забывать, что - Плоское лучше, чем вложенное.

Последние лет шесть использую mobx. При этом в паре проектов была долгоиграющая задача - буквально переписать с reduxa на mobx.

По ощущениям, mobx - это реально серебряная пуля для проектов любого уровня сложности. Особенно это ощущается на долгосроке, при кардинальных изменениях требований и сценариев.

Мобх также позволяет вообще забить и забыть про апи реакта, про все его useMemo, useCallbackи, useContextы и не следить за этим впринципе. Реакт - используется просто как шаблонизатор с предельно тупыми компонентами. Вся логика в сторах, в ооп-стиле, на обычном javascript, сверху вниз. Никакой функциональной вакханалии. На одном проекте, которому пару лет уже - до сих пор нет ни одного useState-а!!

И да, никаких проблем с дебагом, или проблем "скрытой магии" нет вприницпе.

И ещё плюс - бекенд разработчикам понятен код))

дочитайте, пожалуйста, до конца — вас ждет неожиданная развязка.

Думал, что облачный гейминг победит. GeForce Now, premium account - супер. Конечно, речь не про кибер-спорт.

По возможности нужно анимировать только определенные CSS-свойства: transform, opacity, filter, backdrop-filter.

Хмм, а у меня отпечаталось в памяти что всё-что связано не с позицией и не с размерами - анимировать дорого, т.е. всякие прозрачности, тени, фильтры, заливки, градиенты.

Я обычно представляю чуть наоборот.. Event loop - это как раз один бедолага работник, у которого куча менеджеров со своими задачами.)

Перешёл на другую - лучше перезагрузить.

+1! Что говорит о том, что хождение между страницами - и есть нормальный, равномерный во времени, природный механизм инвалидации кеша. И сам юзер это подсознательно понимает - когда хочет увидеть самые свежие данные.

что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.

Расскажите вашу версию, что предпочтительнее использовать - type или interface (чтоб знать что отвечать на собеседованиях). А то, судя по всему, это просто вопрос принятых соглашений на проекте.

формировались новые команды, но мы не всегда могли аккуратно разграничить зоны ответственности 

Очень интересно, что именно не получалось? Не слушались?))

если у вас несколько команд и большое приложение, микрофронтенды – крутое решение

Неужели настолько "круче", чем обычный административный способ. Собрать лидов команд - сказать "Вася, ты со своими ребятами пилите шапку. А ты Петя со своими - будете делать сайдбар. Ваня, ты со своими джунами - полите ui-kit. А мы будем главную. Каждая команда работает в своей ветке. Если будут пересекающиеся вопросы\фичи - организовываем созвон и обсуждаем".

Удобная локальная разработка: работаешь в рамках одного микрофронтенда

И также для локальной разработки очень часто нужно не рамки одного микрофронтенда, а весь контекст проекта целиком. Иначе ж получится - "ничего не знаю - у меня всё работает")