I have a:
The delay option of autoRun is really useful, but it would be great if it supported "leading edge" execution, similar to lodash's debounce function.
The specific problem this would solve for me: I have a function that fetches data from the server, which sometimes is called once, in which case I want it to trigger the fetch immediately, and sometimes called multiple times in quick sequence, in which case I _don't_ want it to trigger on each call.
I could certainly try and submit a PR for this if it sounds like a good idea.
I think you're looking for autorunasync.
https://mobx.js.org/refguide/autorun-async.html
On Thu, Mar 15, 2018, 6:11 AM Øystein Kjærnet notifications@github.com
wrote:
I have a:
- [x] Idea:
- What problem would it solve for you?
- Do you think others will benefit from this change as well and it
should in core package (see also mobx-utils)?- Are you willing to (attempt) a PR yourself?
The delay option of autoRun is really useful, but it would be great if it
supported "leading edge" execution, similar to lodash's debounde function
https://lodash.com/docs/4.17.5#debounce.The specific problem this would solve for me: I have a function that
fetches data from the server, which sometimes is called once, in which case
I want it to trigger the fetch immediately, and sometimes called multiple
times in quick sequence, in which case I don't want it to trigger on
each call.I could certainly try and submit a PR for this if it sounds like a good
idea.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1411, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIrclUob5q_zHkbNjc6MPSyWmXJTvxFks5tekxNgaJpZM4Sr9NU
.
Maybe, but wasn't this removed in v4.0?
autorun(fn, options?) now accepts the following options:
delay: number debounce the autorun with the given amount of milliseconds. This replaces the MobX 3 api autorunAsync
Ok, didn't know that 😀
How about using the debounce number option?
On Thu, Mar 15, 2018, 8:08 AM Øystein Kjærnet notifications@github.com
wrote:
Yes, but this was removed in v4.0
https://github.com/mobxjs/mobx/blob/master/CHANGELOG.md#400:autorun(fn, options?) now accepts the following options:
delay: number debounce the autorun with the given amount of milliseconds.
This replaces the MobX 3 api autorunAsync—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1411#issuecomment-373369775, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIrckg0QSC7PDgL3hGPhXeiEioJl-bIks5temfggaJpZM4Sr9NU
.
You mean delay? That gives the behavior I described above, which is _almost_ what I want, except in the case where the user triggers the function only once - then they have to wait a number of milliseconds before the fetch is triggered. I'd like it to trigger _once immediately_, then after a delay.
Thanks for the quick response, btw :slightly_smiling_face:
@kjarnet PR is welcome! Probably can be incorporated in the scheduler creation utility you will find in src/api/autorun.ts
At the moment autorun actually behaves like a throttle function: it means it fires at most once every delay ms. A debounce behavior (on a trailing edge) should be that it waits delay ms after the last change to fire the view. It means any call in quick succession reset this waiting time.
Since there are 3 more behaviors (leading throttle, trailing debounce, leading debounce), how do you want it to be expressed through the autorun option object? Maybe just providing an explicit scheduler from userland would be enough? [1]
If userland schedulers are indeed enough, MobX could provide a scheduler namespace, just like how comparer currently is
EDIT:
I do not think this is enough as the internal hook onInvalidate is called on all changes but the user-provided scheduler is only called once and not again until it fires the callback, so it cannot act as a reaction selector
EDIT 2:
Since Reaction is still exposed in the API a userland wrapper is possible. If you are going to support it from MobX itself then you just need to decide on item [1]
from top of my head autorun and reaction already support custom schedulers
Op di 17 apr. 2018 om 20:48 schreef quanganhtran notifications@github.com:
At the moment autorun actually behaves like a throttle function (it means
it fires at most once every delay ms). A debounce behavior (on a trailing
edge) should be that it waits delay ms after the last change to fire the
view (it means any call in quick succession reset this waiting time)
Since there are 3 more behaviors (leading throttle, trailing debounce,
leading debounce) how do you want it to be expressed through the autorun
option object? Maybe just providing an explicit scheduler from userland
would be enough?
Or MobX could provide a scheduler namespace, just like how comparer
currently is—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1411#issuecomment-382101211, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhJq8SbuKP4FzuFxIJ951JwIi7R9Qks5tpjj8gaJpZM4Sr9NU
.
@kjarnet Throttling on a leading edge ("cooldown" effect) can be done like this with custom scheduler (I think):
let idle = true;
autorun(effect, { scheduler: f => {
if (idle) {
idle = false;
f();
setTimeout(() => idle = true, 500);
}
}});
autorun supports delay argument.
@mweststrate unless I am missing something, this issue should be closed
@ItamarShDev as I described here, delay doesn't solve this issue, but a custom scheduler might. I haven't been involved with this topic recently to confirm it for sure, though.
Guess this issue could be closed. The scenario can be implement by using custom scheduler. I write a small demo on codeSandBox: https://codesandbox.io/s/n7vjmj0j3m. And just adding option params to autorun still can't meet all the conditions. So maybe leave it to userland will be more sensible. Indeed I think delay is not needed cause it could be easily implement by custom scheduler in a few lines.😀
@fi3ework
it isn't same with debounce-like behaviour. I added clearTimeout to fix this nuance (https://codesandbox.io/s/minimal-mobx-react-project-ins4i), but debounce behaviour still broken... because scheduler does not called if previous callback not called.
Yea, fi3ework said long time ago, let's close it here. Given it has a userland solution, I don't think somebody is interested in implementing it anymore.
Most helpful comment
@ItamarShDev as I described here,
delaydoesn't solve this issue, but a custom scheduler might. I haven't been involved with this topic recently to confirm it for sure, though.