Thoughts on a runloop? about reactive

[lancejpollard]

Here are some links to the implementation Ember has (pretty over complicated, but includes all the key stuff):

• ember-metal/lib/computed.js
• ember-metal/lib/run_loop.js
• ember-metal/lib/observer.js
• ember-metal/lib/events.js
• ember-metal/lib/watching.js

Specifically, observer.js#L63-L72 shows how property changes are batched up.

[tj]

you're free to implement whatever you want really with components, I think if everything was coupled to it that would be the wrong abstraction though. I wouldn't try to cheat browsers too much, they have all sorts of tricks to avoid unnecessary painting etc, plus we can profile these sorts of things for individual components

[lancejpollard]

This is a problem with most/all frameworks that have tried to implement binding, just seems like there should be a standard component/solution to the issue. This is one area where the browsers don't have the appropriate tricks, though they're starting to with the shadow dom and built-in observers.

[tj]

still, a component is just an arbitrary chunk of js, so we can implement things without coupling everything else to it. Just like Emitter happens to be what I use for lots of things, it's not the canonical component solution or anything like that, but that's the great thing about component, you're only opting in to smaller chunks of logic vs a massive framework. For right now I'd favour a nice api over a mess like ember, if anyone hits perf issues we can look into it. So far our app is a lot more responsive than ember stuff like travis etc, anything else would be a premature optimization IMO

[subtleGradient]

Essentially all you need in order to make everything optionally run-loop compatible is a way to opt into do-nothing-until-I-call-flush mode. Then call flush in your run loop as often or infrequently as you like.

So, any chance for that mode in reactive?

[tj]

that should be pretty easy with the adapters, just queue up changes and remove dups etc
https://github.com/component/reactive/blob/master/test/adapters.js#L18

we have a lotttt of moving parts in our app and have yet to see any slow downs from rendering that aren't related to image decoding, that's about the only problem we have right now

[tj]

decided with the upcoming changes it would be good to get these in, but we definitely can do it in ~30 or less lines of code, we don't need all that crazyness, however I still think we should do some thorough profiling. Re-rendering attributes or text multiple times in a tick may be less expensive on average than managing duplicates, or it might be completely negligible, I have an example with 1500 dom reactive templates and it barely registers on the profiler

[defunctzombie]

I think dom stuff already handles waiting on painting until it has to tho request animation frame might be good to throw in the bindings. A runloop is out of scope for now tho.