@Toleckk Как там на редаксе нормально сделать что-то подобное челу? const

$apiType = createStore(‘real’);
const $baseUrl = combine(
$baseUrls,
$apiType,
(urls, type) => urls[type]
);

const requestFx = attach({
source: { baseUrl: $baseUrl },
effect: ({ baseUrl }, params) => axios.request({ baseUrl, …params })
});

apiType положить в слайс, combine заменить на селектор, requestFx на thunk с выбором baseUrl из стора через селектор(getState())

@Zmiterr 💁‍♀️

Думал такой вариант, но в санке инстанс аксиоса создавать показалось дичью

Абстрагировать http client от санок, эффекторов и т.д. надо бы. А то рил дич энивей

Чтобы что? У него буквально логика endpoint -> http client -> baseUrl (from state)

Чтобы, к примеру, клиент был переиспользуемым со встроенным стандартным обработчиком ошибок.

Не стоит делать лишнюю работу на будущее, которая может не оказаться нужной. Делайте всё как можно проще

Я бы согласился, если на проекте используется один апи метод )

Ты путаешь простоту для разработчика и простоту для машины. Ты пытаешься сделать код простым для машины, а не для разараба. Не надо так. Да, код может быть неоптимальным, но достаточным. Каждой оптимизации своё время

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

Нет, должна быть

В чем масштабируемость-то?

Переиспользуемость хттп клиента

Имхо важно чтобы он был стейтлесс

А как же контроллеры для отмены лишних запросов? ))

Сам клиент стейтлесс, запрос стейтфул

Как отменить запрос, если другой про него не знает?

А что ты хочешь отменить на уровне фетчера?

Предыдущий такой же и/или какой-нибудь другой

какой-нибудь другой будет отменяться по бизнес-логике а такой же - состояние конкретного запроса

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

Зачем бизнес логике знать про состояние запросов?

В новом обновленные данные могут быть

Так это твой тейк про “отменить какой-нибудь другой”

Ну это прекрасно, но есть популярный фетчер аполло, который несколько лет уже содержит именно такую логику

Ок, перефразирую, зачем бизнес логике знать про все контроллеры?

А зачем апи-клиенту знать про логику конкретно твоей фичи?

Тот самый второй запрос

Я за абстракцию уровней: апи и бизнес логики приложухи

Какие контроллеры? Ты про запросы? Ну затем, что они оттуда вызываются

Я считаю что дедупликация и кеширование в апи-клиенте МОГУТ БЫТЬ, но возможность отменять другие запросы -- это перебор

Ну если тебе это не нужно, я не спорю ) мне контроль на доп уровне требуется. И работает отлично.

Что делаешь, если отменять запрос Х надо после запроса У или триггера Z, если выполняется условие K?

Зачем это в принципе может понадобиться?

Мне кажется, что он имеет в виду возможность по тегу какому-нибудь отменить запрос извне, а не что апи-клиент сам по себе определяет что и когда ему надо отменять. Если второе, то это оч шаткая система

Нет. Бэк не всегда отвечает успешно - происходит retry. Иногда его нужно отменять (в связи с изменившимся состоянием, но это не важно - хттп клиент не знает про состояние аппки, зато владеет всем, что позволит ему не делать лишнего)