run-loop nit-picks

[stefanpenner]

Typically code that mutates state that is managed by ember should be wrapped in a run-loop

I believe the following may not:

• https://github.com/firebase/emberFire/blob/gh-pages/src/data.js#L72
• https://github.com/firebase/emberFire/blob/gh-pages/src/data.js#L103
• https://github.com/firebase/emberFire/blob/gh-pages/src/data.js#L117-L123
• https://github.com/firebase/emberFire/blob/gh-pages/src/emberfire.js#L26-L32
• https://github.com/firebase/emberFire/blob/gh-pages/src/emberfire.js#L41
• https://github.com/firebase/emberFire/blob/gh-pages/src/emberfire.js#L86-L92
• https://github.com/firebase/emberFire/blob/gh-pages/src/emberfire.js#L96-L101
• https://github.com/firebase/emberFire/blob/gh-pages/src/emberfire.js#L105-L109

It seems like a firebase callback to ember-run aware promise utility method would go along way.
the following seems to be a common pattern.

So this current implementation doesn't really harness some really important aspects of ember and it's run-loop

Let me explain, with XHR it is quite common to have many some what infrequent data updates, when an update happens, we push data into the ember bindings update, observers fire, data settles, and then finally if we need to, we update the DOM.

With WebSockets, or other realtime strategies, it is quite common to have bursts of small updates. Unfortunately currently each update in these bursts will cause change propagation's, that may result in many individual DOM updates. Assuming we get 10 updates in a 50ms window, we would get 10 individual run-loop iterations and up to 10 separate DOM mutations. Interestingly, we would be forcing ember to render at rates greater then even 60FPS, which is wasteful.

In addition if these changes are coalesced into a run loop, they may cancel each other out, result in less or no DOM mutations at all.

Now the above scenario may not effect all classes of applications, but it will effect some.

One potential approach is to batch updates from firebase, and flush them to the ember managed code only at some interval. This interval may depend on the application itself and sometimes may not even be applicable.

[rlivsey]

We handle this in fireplace with a simple event queue [1], any updates are then batched up and handled in the next run-loop. Something similar should be fairly straightforward to implement here I'd expect.

[1] https://github.com/rlivsey/fireplace/blob/master/packages/fireplace/lib/model/event_queue.js

[stefanpenner]

@rlivsey i notice a small comment in your code related to difficulty testing. Debounced/throttled workloads are a pain to test, I would suggest that firebase solution either disable itself for testing, or work it into the testing framework so it can be aware of the async

Also, your solution helps mitigate if a series of "synchronous" or near "synchronous" updates are pushed into ember, but this rate (depending on the app) can still be much higher then when a user can perceive. I would still suggest considering a solution (maybe configurable) that covers a larger window.

[anantn]

Interesting. @stefanpenner, @rlivsey - what do you suggest the default interval to push changes into Ember be? We can make it configurable of course.

[stefanpenner]

well it makes little sense to render at more then 60fps. So (1000/16)ms would be the absolute maximum, depending on the type of application and the rate of data flowing in, I have bumped it up to as high as 50ms or 100ms. But it entirely depends on what that app dictates as an acceptable latency.

[aputinski]

See 2a6c0ec