What Listener, Transition and Scheduler do in Solid's internal API?

I'm reading Solid JS's source code, but I find that there's little comments from code. Solid is much simpler than React, but lots of comments can be found inside React's code. Why there is no comments or document for explaining key concepts?

Please can you explain what Listener, Transition and Scheduler do:

let Listener: Computation<any> | null = null;
export let Transition: TransitionState | null = null;
let Scheduler: ((fn: () => void) => any) | null = null;

Solution

Lack of comments does not necessarily mean lack of documentation but you are partly right as the internal API is not documented enough. I believe there are several contributing factors:

Core team is small and a large portion of the code is written by its creator, Ryan Carniato, and it is maintained by him.
There are not as many optimization tricks as in React code because Solid is fast enough. There are no corner cases and code is clean enough to read through, so most of the time code is the documentation.
Relatively young and evolving project. API stable but its ecosystem is not. It is not widely used in production apps. There are patterns and use cases to emerge. When project matures, it will be re-written and hopefully it will be better documented.
Some concepts require deep and elaborate discussions, others are inherently assumed. A few lines of comments is no place for an elaborate discussion and it would not be sufficient anyway for anyone who lacks the assumed knowledge.
There are long and detailed articles and screen casts on its core logic and design decisions.

Again, exposed API is well documented and has more than enough examples. Internal API is very small and clean enough to read.

Now, to explain the code snippet in the question:

Code belongs to signal's internal API.

Solid is a sync library. Code is executed synchronously and contrary to some other frameworks like React, you never cross async boundary. Point is Solid does not rely on the event loop for running batch updates but juggles code, meaning it pushes a signal's subscribers onto another variable, run state updates (series of assignments and data manipulations), get the stored variables back and notify the subscribers. Solid uses observer pattern.

In Solid each signal keeps its own data like subscribers list. There is no global subscribers queue.

Listener is used by the runtime to store a signal's subscribers temporarily during one of those code juggling and call them back. If I remember correctly runtime store a signal's listener in Listener then does its work. It is better understood in conjunction with a scheduler and batch updates.

Transitions are used for async consistency. They store state updates while a related asynchronous task is completed. Say you are rendering remote data tied to a query parameter like a page number. When you update the page number, an intermediate state will be crated and request will be sent but actual state update will be stored in transitions, which will run once the request settles down. Main idea is the page number and the rendered data that is tied to the page number always consistent. It is a form of batch updates but tied to async an async task.

Scheduler is used scheduling UI updates. In regular pub-sub model, subscribers are called back and chain of events are run at once and undisturbed. But it is not optimal if you have many moving pieces. Scheduler allows Solid runtime to switch tasks while running effects. By running effects I mean calling subscribers back.