-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debounced computeds #283
Comments
If you want to create a PR, this seems like a useful function 👍. |
Hi @pimterry |
One example in my application: performant free-text filtering over lots of data. I have a free-text entry field where you can type in strings to search for in a large data set. The searching is quite expensive. A simple approach would be to have a computed Instead I debounce this computed, so it only runs every 250ms. This means:
This can happen repeatedly, e.g. if you're typing constantly for a second it should update the filtering 5 times throughout that time (0ms, 250ms, 500ms, 750ms, 1s) instead of every single key press. This does potentially result in an inconsistent data model (e.g. in this case the filter input and the filtered results might be out of sync) for up to the max duration of the debouncing, but it should always settle into the correct in-sync value by the end. My current code for this is here and there's a few quick tests here. It's used by just decorating the getter with |
@pimterry One question. I have a class that I make Thank you! |
No idea, sorry! I'm still using decorators instead, and I'm actually using Mobx 5 anyway so there might be minor differences there. |
Thank you @pimterry, for the valuable information. For other, will ask chatgpt |
I've been playing with debouncing computeds. I have a complex & CPU-expensive computed that subscribes to many observables, and I'd to debounce recalculations there.
I haven't been able to find a nice way to do this. #24 gets close, but was never merged, and only works for debouncing downstream updates, not debouncing incoming updates, so isn't really sufficient (unless your computed has only one or two inputs).
I know this breaks the general contract of
@computed
, fully agree this shouldn't be a common case, but I do think it's a useful niche case. I've got the below currently working as drop-in alternative for@computed
decorators, which I think works nicely.A) Is there anything obviously wrong with this approach, or any other existing alternatives I've missed?
B) If not, would you be interested in including it in mobx-utils?
I'm still using mobx 5, but as far as I'm aware the same concept (same code?) should work just the same in v6.
The text was updated successfully, but these errors were encountered: