Шортхенды для вызова query после мутаций и / или других query (операторы success, failure)

[xaota]

Часто требуется загружать данные после получения других данных или (ещё чаще) обновлять их после мутаций

Текущая реализация (даже с учетом #465) слишком многословна. А если требуется делать mapParams, то наступает полный мрак.

Идея - базовые операторы success и failure для простого описания порядка запросов

пример:

const queryFirst = createQuery(...);
const querySecond = createQuery(...);

const mutationFirst = createMutation(...);
const mutationSecond = createMutation(...);

success(queryFirst, querySecond, mapParams?) // после успеха queryFirst будет вызов querySecond (и mapParams тут же)
failure(mutationFirst, queryFirst, mapParams?) //  в случае неудачи mutationFirst надо перезапросить queryFirst

// и так далее

[igorkamyshev]

Чем плоха форма

update(query, { on: mutation, by: { success: true } })

?

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

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

https://github.com/igorkamyshev/farfetched/blob/master/CONTRIBUTING.md

[xaota]

update(query, { on: mutation, by: { success: true } })

1) эта запись РЕЗКО усложняется, если требуется mapParams, например 2) а можно сделать update(query: querySecond, on: { query: queryFirst, by: ... })? как будто бы в терминах этого оператора не очень хорошая идея

вообще идея в том что это просто шортхенд для самых частых кейсов типа success(mutationFirst, querySecond), можно такими короткими кирпичиками описать флоу запросов, и читать очень удобно

[risen228]

Есть вот такое еще предложение

update(usersListQuery)
    .onMutationSuccess(addUserMutation)
    .setResult((list, user) => list.concat(user))

update(usersListQuery)
    .onMutationFailure(addUserMutation)
    .setError((queryError, mutationError) => mutationError)

update(usersListQuery)
    .onMutationFailure(addUserMutation)
    .doRefetch()

Про проблему часто писали в чатах, сейчас апишка тяжеловатая и внутри надо делать тайпгард у квери чтобы отсечь кейс когда у нее состояние ошибки, из-за этого код очень некрасивым и многословным становится, с конструкциями вида if ('error' in queryResult) return

Хочется иметь апишку которая позволяет написать логику апдейта под кейс когда квери не в состоянии ошибки (или наоборот только когда в состоянии ошибки), и не сужать ручками типы

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

Также можно добавить методы для ивентов, например:

update(userListQuery)
  .onEvent(userAdded)
  .setResult((list, user) => list.concat(user))

Есть мнение что это не совсем effector-like апишка и она должна быть объектом как во всех операторах. Но вложенность тогда выглядит неприятно и это не так удобно писать, в отличие от чейнинга

На полноценную RFC нет времени и сил, сорри