Open oppianmatt opened 7 years ago
There was a PR in the past that did something similar. Although conceptually I think this is cool, I pushed back on it being in the core as I feared it could lead to in consistent behaviour across devices of varying abilities.
For example, say your using FastDOM to construct a complex layout, on a fast device all the work may get done in one frame, but on slower devices it may get spread across frames, resulting in a more 'progressive' style render.
I'm willing to be proven wrong though :)
To your earlier point of allowing extensions to override the core task flush logic: this seems fragile to me. IMO how fastdom chooses to run the tasks should be abstracted from user/extension land. I say this as I think we'll probably break extensions if we choose/find new optimizations further down the road.
I think the best solution in this case would be to add this particular logic to the core, but preffed off by default. This means that users can opt-in to more unpredictable running of tasks in exchange for some smart flushing and we can keep the task flushing logic private from extensions.
The downside is that we'll bloat the core a little. Right now my suggestion would be for you to run your fork in production for a while and report back any issues that arise. If the patch proves to be truly valuable we can merge it into the core.
Thanks for your time on this, it's really interesting. Hope my feedback helps :)
@oppianmatt did you ever execute on this in prod?
I wanted to extend fastdom to process tasks in a different way. Specifically I wanted to use the advice from https://developers.google.com/web/fundamentals/performance/rendering/optimize-javascript-execution to break up the tasks so only a few ran per frame. Currently fastdom runs all the tasks in a flush. So if you have queued up a bunch of tasks you still can get a javascript violation warning if the code ran for too long.
The google link provides an example like:
I've managed to modify fastdom to incorporate that but would prefer to do it in an extension rather then modifying the main.
This was my first attempt at putting it into fastdom (only the changed methods):
Basically it processes the task, measuring how much time has passed and if it hasn't been too long keeps processing the tasks. If no time left it throws an exception which is caught and ignored, but used to queue up for a next round.
Might be a better way that doesn't involve throwing exceptions (I'm a pythonista, exceptions are the norm). But I don't see any way to currently use extend to modify fastdom for this behaviour.