corrections are welcomed as my understanding of solid reactiviy is limited

(sources) signals are the sources of truth.

(pure derivations) we derives values from signals by storing computations from signals using functions, or memos(lazy/eager) if we want to be efficient by calculating only when necessary then we need to actually show the values, and we do it using render effects, which are also pure from the viewpoint of the system

(impure derivations) then another kind of effects for us/users to do whatever we want, known as user effects to the system and just effects to us

now, when we update the sources, everything that depends on them happens synchronously synchronous means things happen sequentially and consecutively without any gaps in between, you can't stop it, neither can you observe it, you can only know when it's done in simple words, it's blocking

whether we group the updates and apply altogher or not is a choice and solid chose not to by default, which might change in solid 2.0 iirc, and allows explicit grouping using batch

asynchronous, on the other hand, does not block and also puts meaning to previously scattered synchronous events to be able to say, which and which events belong to some specific value, promises as we know, i.e initial, pending, resolved, etc all bound to a single value

now, solid also allows deriving from these values (promises) using resources but it isn't aware of the above fact and updates still happens separately and synchronously throughout the asynchronous stages

you would see the changes in all stages if you display the values

but what if we only care about start and end like we do for synchronous values, in a sense we want to pretend asynchronous as blocking as it's were synchronous

surely you can for a single resource by selecting which parts you do want

but how would you do it across multiple resources? i.e how would you group the operations across multiple resources? they might exist underneath the UI tree and you would not have access to these at all.

enters Suspense, which allows us to group any resources deep under the tree and we get the ability to a) show whether they are in-operation(pending) and b) show all of them altogether when all of them have finalized their states

but what if we only care about the finalized state and want to only show just that? enters Transitions (or Transactions as it should be and Ryan's gotten to renaming to it recently)

now, in addition to grouping asynchronous reactivity of resources like suspense, we can also choose to keep show the current states unlike suspense which only can chose to or not to display them, with a placeholder for the latter case

how does solid do it exactly?

we can't change anything that resides in current reactivity tree because that means altering/tampering with current values which is what we are trying to avoid and what suspense also does by showing a fallback.

in S.js (which Solid took inspiration from), you can create another reactivity tree, which is known as Subclocks or forking. Here, the default system is know as the Clock. at first encounter, i didn't really understood what it was for. it seems like an unnecessary leaking of internal implementation details.

in solid, instead of allowing creation of subtrees, the current system is modified to handle two reactivity states. one for default reactivity and another for transactions. but this fork doesn't need to handle things in the same way the default one does.

the initial problem was suspense can't group asynchronous reactivity of resources without affecting the default system, so this fork's only purpose is to handle these cases specifically.

you can see this check Transition && Transition.running in many places throughout the solid source code, but not everywhere it could be for above reason.