You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The usecase is to throttle touchmove events in the dom. As of now we have to schedule it via mutate and then clear it when the next one comes. This can't be done easily and one needs to write a wrapper sort of like this —
The second problem is that it should be performing poorer because of the time complexity of n to remove an element from the queue.
The text was updated successfully, but these errors were encountered:
tusharmath
changed the title
[Feature Request] Helpful to add and clear the last one
[Feature Request] Helpful util to add and clear the last one
Aug 23, 2016
tusharmath
changed the title
[Feature Request] Helpful util to add and clear the last one
[Feature Request] Helpful util to add and clear the last task
Aug 23, 2016
Do you need fastdom to clear? When a touchmove event happens grab the coords (or whatever you need) and save it. Then queue up a raf to process it if it's not queued already. In your processing part that's where you use mutate/measure or whatever. And you won't need to cancel anything.
Basically you want your scroll/move handlers to be as fast as possible and finish quick. Less work the better. So the most they should do is save some variables and queue up a tick if not already queued. In the tick is where you do you work.
The usecase is to throttle
touchmove
events in the dom. As of now we have to schedule it viamutate
and thenclear
it when the next one comes. This can't be done easily and one needs to write a wrapper sort of like this —The second problem is that it should be performing poorer because of the time complexity of
n
to remove an element from the queue.The text was updated successfully, but these errors were encountered: