А в вашем случае цепочка событий это что?

"сходить на сервер за данными для фильтра, для графика и прочее."

Я имею ввиду в реализации)

можно заюзать bluebird промисы и их отменять

+

Ну или core.async если уж на то пошло?

в реализации это обычные re-frame events просто в :async-flow

А… Я не использовал async-flow, но суда по документации оно пуляет re-frame ивенты по очереди?
Если это так и в самой библиотеке нет возможности остановить «флоу» то тут, как мне кажется, 2 варианта.

Первый (костыльный) это в каждой функции, которая выполняется в цепочке, проверять какой-нибудь флаг что юзер отменил запрос. Если этот флаг true, то не выполнять функцию.

Второй вариант это использовать промисы/Rx/core.async и сделать так, чтобы ваша цепочка загрузила сама все данные и потом в конце пульнула один единственный эффект со всеми предзагруженными данными. В этом случае вы можете отменить и промис и rx-chain и закрыть core.async-канал

Дай всем запросам id или tag - и на событие отмены - отмени все запросы

напиши свой xhr effect - для полного контроля

core.async stateful зло

кстати думл о таком, чтобы если одно событие диспачит другое чтобы оно передавала ему свой tag
и так по цепочке

Коллеги, а расскажите про Graph QL чуть-чуть
Интересно:
– Какие у вас любимые статьи по нему?
– Какие графы можно в нём смоделировать и опрашивать?
– Какие границы у него?
– Есть ли там концепт полноценных рёбер с собственными атрибутами? (e.g. чтобы между двумя вершинами могли быть рёбра разного типа)

есть мнение, что graphql не совсем про графы

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

к графам имеет очень опосредованное отношение

а что есть из хороших пейперов про запросы по графам?

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

перенести их внутрь  :)

Внутрь клиента, это важно