[feature] useDebouncedRefHistory - History with delayed recording
See original GitHub issueHistory will commit changes not immediately but after the given number of milliseconds, which will be received by the third parameter
const history = useDebouncedRefHistory(source, options, ms)
I think it’s easy to do it by copy and slightly changing the code in useRefHistory. One needs to wrap manualCommit in useDebounceFn which accepts ms
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (14 by maintainers)
Top Results From Across the Web
useDebouncedRefHistory - VueUse
Delay (in ms):. History (limited to 10 records for demo) ... declare function useDebouncedRefHistory<Raw, Serialized = Raw>( source: Ref<Raw>, options?
Read more >useDebounce React Hook - useHooks
This hook allows you to debounce any fast changing value. The debounced value will only reflect the latest value when the useDebounce hook...
Read more >Debouncing with React Hooks - DEV Community
Today I'm going to show you how to build a useDebounce React Hook that makes it super easy to debounce API calls to...
Read more >Difference Between throttling and debouncing a function
To put it in simple terms: Throttling will delay executing a function. It will reduce the notifications of an event that fires multiple...
Read more >How to Use Debounce and Throttle in React and Abstract ...
For brevity, consider debounce and throttle from Lodash. If you need a quick refresher, both accept a (callback) function and a delay in ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
eventFilter
foruseRefHistory
, following other composables.extendFilter
would only be used for filters likepausableFilter
. In the future, I would prefer to have acomposeFilter
util so we dont need to add theseextendFilter
params to every filter.Awesome! And ya, there is no need to have
composeFilter
now. As more filters are added, it will be more important.About the
extendFilter
param, I think we should use the same convention as other composables and useeventFilter
here. It would be good at one point to changeextendFilter
toeventFilter
inpausableWatch
too (it could be made with a deprecation without a breaking change). The nameextendFilter
implies that there is a filter already in use internally but that is an implementation detail. Looks likepausableWatch
is the only one with this naming convention.