Open aSugarRush opened 1 year ago
Hi!
That's an interesting idea. How do you imagine for the comparison to look? For example, React scheduler can't be used outside of React so it won't be a direct comparison. I guess something more like A works like that and B works like that written in text and not in code examples or test cases?
I'm using Solid in my own projects. As far as I know, Solid doesn't have async scheduling that goes beyond a single task.
Yeah, I think that a comparison more on technicalities would be good, code examples would be more difficult to do since they are not directly comparable (as you mentioned).
I noted for example that your API is more centered about utility functions for more granular control (isTimeToYield and yieldControl). Solid's one is more like a queue of task that are resolved ASAP without priority distinction, and you can only give it tasks to enqueue (not in the public API I think).
It would also be cool to know how the Prioritized Task Scheduling API could be used for the same purpose.
I did some digging into this rabbit hole since I wanted to create my own scheduler for a personal project, I took some inspiration from this library (thank you in advance), as well as Solid's one, and tried to mix it with some ideas from Idle Until Urgent strategy.
Great ideas. Thanks! I can work on some of those. Maybe first, I want to improve the library in general. I have ideas for a refactoring and better scheduling techniques in general.
What are you working on? Would you like to share it or is it something for private use?
Sounds interesting, I'll be paying attention on that.
In my case I find it fun to work on complicated, sometimes low-level things to code. So... why not to make an entire javascript framework as a side project? there are not many of them out there (/s).
I worked on how to schedule the tasks it may perform, In my case I have 4 priorities, from highest to low. I use the highest priority for DOM updates and the other tree depending the case. My API is something like:
export type Priority = Low | Medium | High | Highest;
export type Process = Generator<VoidFunction>
function batchProcess(process: () => Process, priority: Priority): Promise<void>
A Process is a bunch of tasks that needs to be executed, I went for a Generator since I found it more practical.
The highest priority executes as many tasks as possible using MessageChannel and checking if a yield is necessary. The other 3 priorities only execute one task at a time and yields, it uses the Prioritized Task Scheduling API (if available), or uses Promises that are resolved depending on the priority:
Dunno if it's the optimal way to do it, but I'm pretty happy with the result (wouldn't mind some opinions)
I like what you are doing. I think it makes sense. Thank you for the entire discussion as it gave me ideas for my own project as well. I started exploring the possible use of postTask()
inside of main-thread-scheduling
, we will see how it goes.
About the comparisons, I think a webpage with examples and showcase + benchmarks would be ideal for the project because the project itself is hard to wrap your head around.
Also, please add a link to your repo here in the comment if you decide to open-source your implementation. If it's in a bigger project, point to the part that handles scheduling.
I'll like to see a comparison between this library and other approaches followed by some frameworks, like react or solid.js (the latter being a simplified version of the former).
I know that solid for example doesn't have different priorities for its scheduler, I'll like to know how much it benefits to do the distinction between 'user-visible' and 'background' in your approach.