ReactiveHTML
Node-based schedulers overwrite tasks
Schedulers like src/schedulers/ema-animation-frame group/debounce tasks by node in order to skip updates that would overwrite previous ones.
Tasks should be grouped by node AND task type (e.g. innerHTML task, attribute change tasks, etc) otherwise different tasks on the same node may overwrite each-other. An innerHTML task may overwrite an attribute change task.
Queue only using node as a key:
https://github.com/ReactiveHTML/rimmel/blob/master/src/schedulers/ema-animation-frame.ts#L35
Hello @dariomannu ,the conflict might be arrising due to Set not being able to distinguish between node and task type which can be done as a key value pair using a map . please do assign me this issue under the hacktoberfest tag
Hi @pranavgaur354-cloud, that's a great insight!
The task is all yours! If you like Rimmel, feel free to drop a star on the project to help the algorithms better spread the word...
If you need any assistance, just shout.
Hi , apologies for the late update . I have found a way to map both node and task type to it . I have also wrote a test for it aswell . Will share it ASAP .
hello again , i have some doubts regarding the usage rendering task as
in RenderingScheduler
export type RenderingTask = SinkFunction;
But SinkFunction is (values?) => void( the returned function.)
However, we need to group by task type, which is the Sink function itself (e.g. contentSink, attributeSink), not the SinkFunction. so should RenderingTask be changed to:
export type RenderingTask = Sink
The SinkFunction is the task itself, so it could also be used as an indexing key in a Map or a Set. We could have a map of nodes, the values of each could be a map of tasks (key is the sink function and value is the node-bound actual function instance).
Otherwise, we could also have a set of {node, task} objects, which would be the keys, and then we'd walk the set to run everything we find in it
Because of "locality" I have a feeling like a map of nodes => map of tasks might be more efficient on the DOM, so you would run all tasks for a given node in one go before moving on to the next node, but only numbers could confirm this will actually be the case.
Unless I've missed something, RenderingTask seems correct to be a SinkFunction. A Sink is a "preloader" of a SinkFunction. It runs when mounting a component, gets the node as a parameter and returns the sink function, bound to the node for performance if possible.
Anyway, Sink and SinkFunction are a bit confusing in the naming... whenever two better names come up, I'm happy to improve them
Yeah, interesting idea, in theory that could work, too. The implication is that if two different sinks return the same sink function (at the moment I believe we may have one or two of these), their tasks would be processed as part of two separate queues, so out of order.
Do you believe it would be better to use the sink for indexing? If yes, let's do it. Schedulers are experimental at the moment, so it's definitely a good time to experiment with them... 🚀