Feature/observable throttle#363
Conversation
|
Yeah, I can try in my app! (just feel that comfortable delaying 16ms, hope we can find a better way later) |
|
We could easily solve it if Meteor expose callback for Cursor change by DDP message (can easily implemented by using hash for each DDP message, and update the hash of the Cursor only if the DDP message relevant to the message). |
|
@dotansimha I am using #3eaca130942872f95c761d413af8074a991e08c1 3 products in database. For me, After unsubscribing, note the first one's
|
|
Ha, that is one of main reasons that I love ngrx (Redux). It helps you know how Meteor reactivity works, and when it runs. And nice for performance, making it exactly runs once, not twice. |
| observer.next(cursor.fetch()); | ||
| }; | ||
| var rawHandleChange = function () { return Zone.current.run(function () { return observer.next(cursor.fetch()); }); }; | ||
| var handleChange = _.throttle(rawHandleChange, COLLECTION_EVENTS_DEBOUNCE_TIMEFRAME, { trailing: true }); |
There was a problem hiding this comment.
@dotansimha What do you think if we put _.debounce here instead _.throttle? I feel like it might be a better fit here since _.throttle always runs the callback every 16ms and _.debounce groups calls together based on the 16ms gap.
There was a problem hiding this comment.
Sounds good. I will try it.
|
@hongbo-miao @barbatus @Urigo @hongbo-miao what do you think ? |
|
Thanks for the awesome work! |
@hongbo-miao @Urigo
What do you think?
Looks now that the
fetchcalled only twice when you have a lot of objects, and once when you unsubscribe from the Meteor publication.I chose 16ms because it's the minimum timeframe between WebSocket messages, and under that is too fast (it's equivalent to 60fps).
@hongbo-miao Do you have any use case you can try besides the example I provided?
Thanks