Я такую же сделал, лол Но это не айс, на самом деле

потому-что не будет работать для цепочки промисвов?

я считаю что отмена промиса это бред

Промис с отменой — это два встречных промиса

Один из которых является токеном для отмены другого

я считаю что отмена промиса это бред

Декларативная отмена промиса просто означает что результаты его выполнения нам больше не интересны

Декларативная отмена промиса просто означает что результаты его выполнения нам больше не интересны

я вижу промисы как async/await

как если const foo = getFoo()

как отменить getFoo()

что будет в foo?

null?

undefined?

Очень резонный вопрос, это действительно неоднозначно

Все по разному это расценивают

что будет в foo?

этот асинк в итоге возратит промис, ну ииии ты уже просто отменяй конечный промисс, а не промежуточные

этот асинк в итоге возратит промис, ну ииии ты уже просто отменяй конечный промисс, а не промежуточные

это вообще не промис

этот асинк в итоге возратит промис, ну ииии ты уже просто отменяй конечный промисс, а не промежуточные

отмени мне вызов обычной функции

axios падает с CancellationError (на случай когда reject нежелателен там предусмотрен rejectInterceptor)

отмени мне вызов обычной функции

а для чего такое делать?

я когда-то писал такое: https://github.com/LestaD/timeout.js/blob/master/src/timeout.js

а для чего такое делать?

так и я ж об этом

написал свою реализацию. Как думаете - норм? или какашка? https://repl.it/KUE8

https://medium.com/@benlesh/promise-cancellation-is-dead-long-live-promise-cancellation-c6601f1f5082 Я только вчера сидел изучал) Я сейчас как занимаюсь проблемой отмены асинхронных вызовов

а для чего такое делать?

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

Пацаны, подскажите плз чатики iOSеров?

так и я ж об этом

ну, мне надо, у меня в реакте setState делаеться по возращению результата промиса, а если пользоваетль демонтировал компонент, и пришел запрос, вот тут и нужно отменить промис

ну, мне надо, у меня в реакте setState делаеться по возращению результата промиса, а если пользоваетль демонтировал компонент, и пришел запрос, вот тут и нужно отменить промис

ну а если бы ты просто делал долгую функцию?

как бы ты решал проблему?

ну, мне надо, у меня в реакте setState делаеться по возращению результата промиса, а если пользоваетль демонтировал компонент, и пришел запрос, вот тут и нужно отменить промис

const data = calculateData() this.setState({ data }) реши

проверкой типа

какого

функцию calculateData нельзя отменить

как бы ты решал проблему?

nextTick, requestIdleCallback

ну тогда все заблочиться, пока она не отработает ?

самое простое решение которое я вижу class Demo extends Component { mounted = false componentDidMount() { this.mounted = true getData().then(data => { if (this.mounted) this.setState({ data }) }) } componentWillUnmount() { this.mounted = false } }

раз девелоперы решили выпилить isMounted

самое простое решение которое я вижу class Demo extends Component { mounted = false componentDidMount() { this.mounted = true getData().then(data => { if (this.mounted) this.setState({ data }) }) } componentWillUnmount() { this.mounted = false } }

это первое что приходит в голову

отмена промиса это жесть

Фактически это cancellation token as it is

костылить ради чего?

зато явно

но я бы заюзал flutures

и код почище был бы везде

зато явно

А потом тебе надоест, и ты захочешь абстракцию.

И будет неявно. Хе-хе.

А потом тебе надоест, и ты захочешь абстракцию.

и я напишу HOC

В futures кстати круто то, что ты явно задаёшь функцию для отмены

В результате фактически имеем деструктор для ресурсов

А потом тебе надоест, и ты захочешь абстракцию.

withDataRequester(getData)(MyComponent)

и я напишу HOC

HOC?.. Промис?.. Ээээ

А човаще надо было?

чтобы не выполнился setState в .then если компонента больше нет

Рендерить чо-нить по событию?

самое простое решение которое я вижу class Demo extends Component { mounted = false componentDidMount() { this.mounted = true getData().then(data => { if (this.mounted) this.setState({ data }) }) } componentWillUnmount() { this.mounted = false } }

мне мой вариант нравиться тем, что я сделал один раз ф-цию, прокидаваю туда промис и получаю возможность его отменять, в твоем же варианте, это в каждом компонентие нужно заводить переменную, писать componentWillUnmount, поэтому нельзя будет юзать компоненты функции, и блин в каждом компоненте писать это не айс, это не DRY

чтобы не выполнился setState в .then если компонента больше нет

Это кстати в хэндлерах recompose из коробки, что круто

мне мой вариант нравиться тем, что я сделал один раз ф-цию, прокидаваю туда промис и получаю возможность его отменять, в твоем же варианте, это в каждом компонентие нужно заводить переменную, писать componentWillUnmount, поэтому нельзя будет юзать компоненты функции, и блин в каждом компоненте писать это не айс, это не DRY

HOC один раз написал прокидываешь туда функцию оно само делается ничего даже писать не надо и .cancel вызывать да ещё и мозги не выворачивает)

HOC один раз написал прокидываешь туда функцию оно само делается ничего даже писать не надо и .cancel вызывать да ещё и мозги не выворачивает)

кучу хоков тоже не лучше моего варианта

лол

мой вар дешевле

ну пиши)

че спрашивать у сообщества

Дешевле рекомпоуз.

То есть, застряв в той же проблеме что сейчас Sergey, я обнаружил, что смена явной функции класса на хэндлер из recompose решает проблему

То есть, застряв в той же проблеме что сейчас Sergey, я обнаружил, что смена явной функции класса на хэндлер из recompose решает проблему

имеешь ввиду withHandlers?

Сергей, вот тебе кратчайший путь.

имеешь ввиду withHandlers?

Да, они просто не вызываются если компонент уже отмонтирован

Да, они просто не вызываются если компонент уже отмонтирован

чет у меня вызывались и падали

Ну это наверное от кейса зависит

ERROR: S client not available

хотя может я че не так делал

Надо разковырять эту проблему только для того, чтобы разобраться, как работает, но это потом. А чтобы зарелизить фичу, бери рекомпоуз.

Ну это наверное от кейса зависит

withState('name', 'setName', ''), withHandlers({ onClick: props => data => event => { props.setName(data.name) } }) <button onClick={props.onClick(item.name) /> чет мне кажется так не прокатит

Надо разковырять эту проблему только для того, чтобы разобраться, как работает, но это потом. А чтобы зарелизить фичу, бери рекомпоуз.

в следующем проэкте, у меня бандл уже большой, не хочу еще рекомпос тянуть

withState('name', 'setName', ''), withHandlers({ onClick: props => data => event => { props.setName(data.name) } }) <button onClick={props.onClick(item.name) /> чет мне кажется так не прокатит

А ты сохзрани setName в переменную.

withState('name', 'setName', ''), withHandlers({ onClick: ({ setName }) => data => event => { setName(data.name) } })

withState('name', 'setName', ''), withHandlers({ onClick: props => data => event => { props.setName(data.name) } }) <button onClick={props.onClick(item.name) /> чет мне кажется так не прокатит

Можно сам setState тоже на рекопмоз свалить

Можно сам setState тоже на рекопмоз свалить

так свалил же

withState('name', 'setName', ''), withHandlers({ onClick: ({ setName }) => data => event => { setName(data.name) } })

разве разница есть?

У тебя на момент обращения к setName же падает?

Типа её не существует?

так свалил же

А, точно Хз тогда короч

Я просто другого кейса не могу придумать.

У тебя на момент обращения к setName же падает?

нет, пишет "компонента нет"

Хм.

я в итоге написал hoc который разруливает всё сам

оч удобно

Вообще сложная тема, даже автор rxjs в статье выше пишет что с отменой у них не всё гладко

ну поэтому я не отменяю, а проектирую так, чтобы отмена не понадобилась

хотя isMounted, тоже своего рода отмена но тут скорее игнор результата, нежели отмена

Дак я тебе про это сразу и сказал)

Декларативная отмена промиса просто означает что результаты его выполнения нам больше не интересны

видел такое getData(props.id) .then(checkMounted(this)) .then(data => this.setState({ data })

Декларативная отмена промиса просто означает что результаты его выполнения нам больше не интересны

Причём это сейчас так например в axios и в bluebird

The new cancellation has "don't care" semantics while the old cancellation had abort semantics.

axios просто выкидывает результат, но не разрывает соединение?

Хм, не, гоню про axios

Он падает с CancellationError

И имеет встроенные средства для того чтобы ты мог заигнорить эту ошибку если хочешь

open new issue?