Cancel для pull обновлений about cellx HOT 8 CLOSED

Еще как очистить закэшированное в a значение, если надо заново перевытянуть a?

from cellx.

обрывать загрузку

Вот не надо так делать), я давно уже подробно описывал свои мысли на эту тему, сейчас не могу найти, но если кратко, то в 99% случаев не нужно отменять никакие запросы. Что происходит когда вызывается какой-нибудь abort у XHR? Разве посылается ещё один запрос, который "догоняет" в сети предыдущий и говорит ему отмениться? Нет конечно, сервер так же потратит свои ресурсы и сгенерирует ответ, отменяется только реакция на него, и вот эту реакцию никогда нельзя отменять где-то выше, отменять её нужно непосредственно в месте её описания. Простой пример, при развитии приложения сервер стал умнее и научился комбинировать запросы (GraphQL), на клиенте переписали слой доступа к данным научив его не моментально посылать запросы, а через setTimeout(cb, 1), комбинируя их. Дальше одна из въюшек умирая отменяет запрос полностью, но в нём было что-то и для другой въюшки, которая теперь просто не получит то, что просила, хотя никакой ошибки не было. Это лишь одна из подобных возможных ситуаций. Примерно тоже самое и с ячейками, в примере выше на a может быть подписан ещё b2, или на b может быть подписан c, они тоже что-то там попросили загрузить и вот им эта отмена никак не нужна. Отменять нужно непосредственно обработку b и это, скорее всего, будет просто снятие обработчика с него. Для отмены реакции на запросы в компонентах я использую registerCallback, как-то так:

loadContacts(/* args */).then(this.registerCallback(() => {
    //
}));

У умирающего компонента будет вызван dispose (componentWillUnmount для реакта) и всё, что было обёрнуто в this.registerCallback в этом компоненте будет отменено только непосредственно для этого компонента, но ничего лишнего.
Я не знаю конкретно твою ситуацию и зачем тебе такое понадобилось, но почти наверняка в месте создания b ты просто не должен хотеть отменить a, в месте создания b ты должен хотеть отменить только b, а отменять a должно хотеться только там где он и создаётся. В результате во всех случаях там, где правильно отменять загрузку ячейки, там же и создаётся эта ячейка и научить её отменяться можно просто допилив её pull. То есть дополнительные методы просто не нужны. Если что-то отменяется на уровень выше, то это почти наверняка (возможно всегда, исключений я пока не встречал) архитектурная ошибка.

Еще как очистить закэшированное в a значение, если надо заново перевытянуть a?

#7 (comment)

from cellx.

1. http запросы и промисы - частный случай, не надо на их реализацию завязываться, лучше на observable. Один раз запросил - далее приложение постоянно будет слушать сокет и занимать ресурсы и это не отменить никак:

const a = cellx(function(push, fail, oldValue, onCancel) {
   const observable = request.observable('http://...')
   const subscription = observable.subscribe({
      next(res) {
         push(res.value)
      }
   }) 
    onCancel(() => subscription.unsubscribe())

    return oldValue || 0;
})

1. registerCallback в компонентах это костыль, такой же как в push-архитектурах инициация загрузки в componentDidMount. Компонент не должен что-либо знать о загрузке данных. Вообще слово компонент я бы не употреблял, в общем случае это абстрактный потребитель, consumer, который делает одну вещь - subscribe/unsubscribe, оповещая атомы о своем mount/unmount, далее все можно автоматизировать. Pull ведь именно для этого придумывался, для автоматизации рутинных действий по подписыванию/отписыванию, инициации загрузки и т.д, ведь тем самым кода и ошибок меньше, инкапсуляция лучше, т.к. компонент знает только о данных, а не о способе их загрузки.
2. Например, можно считать число ссылок на атом с pull по кол-ву вызовов subscribe, по первой ссылке - вызываем pull, по последней - cancel, Вот если б потребители "протекали" во все атомы с pull. На этом же принципе можно делать автоматизацию dispose.
3. По поводу очистки кэша ок, правда есть один момент: value('pull', 0); // заставляем ячейку перезапросить данные.
   В нормальный компонент этот value не приходит, а приходит computableValueA, который использует computableValueB, который использует value. И если мы хотим ресетнуть значение, нам ради этого придется раскрыть компоненту или экшену/сервису/etc, что есть еще некий value, который надо ресетнуть. А если в ходе рефакторинга value стал computable, а загрузка стала теперь в value0?
   Как сохранить инкапсуляцию и косвенно воздействовать на value через computableValueB или еще что-то?

from cellx.

считать число ссылок на атом с pull по кол-ву вызовов subscribe, по первой ссылке - вызываем pull, по последней - cancel

Опция reap вызывается при снятии последнего обработчика (в том числе со всех зависимых ячеек):

let a = cellx(() => Math.random(), { reap() {
    console.log('reap');
} });
let b = cellx(() => a() + 1);

let listener = function() {};

b('subscribe', listener);
b('unsubscribe', listener);
// => 'reap'

В нормальный компонент этот value не приходит, а приходит computableValueA, который использует computableValueB, который использует value

достаточно вызвать pull у computableValueA, он вызовет его у всех родителей.

from cellx.

Понял, хорошее апи. mobx с derivable далеко до этого, а я задолбаюсь для них писать плагины под atmover.

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

from cellx.

Да, давно уже надо дописывать, времени совсем не хватает((.

from cellx.

Так, значит в reap можно отменить запрос и этот reap сработает при снятии всех обработчиков со всех дочерних ячеек (им этот запрос и понадобился, но раз обработчиков нет, то уже не нужен). Вроде этого должно хватать? Закрываем?

from cellx.

Да, норм

from cellx.