Transaction

This object holds a queue of callbacks that should be executed when all observables finish starting. This lets signal.changes streams emit the updated signal's value when restarting, in such a way that the value propagates to all new observers instead of just the first new observer that triggered restart.

For that to happen, you need to wrap the code that's adding several observers into onStart.shared. We do this in a couple places in Airstream, and in a couple places in Laminar, and this seems to cover most reasonable use cases. Users might need to wrap some of their code into onStart.shared manually if they manage subscriptions manually.

See https://github.com/raquo/Airstream/#restarting-streams-that-depend-on-signals--signalchanges-

Create new transaction.

Typically used in internal observable code.

Warning: It is rare that end users need to manually create transactions. Example of legitimate use case: Var transaction delay

How many nested transactions you can have.

Airstream will refuse to schedule any transaction that exceeds this limit. This will prevent the content of the transaction from running, so this could leave an event not fully propagated. This is, of course, an undesirable situation, so you should never hit this limit.

It is very hard to deliberately write valid code that would hit this limit. If you are hitting this limit, most likely:

• There is an (unterminated) infinite loop in your observable graph, e.g. two Var-s updating each other recursively, or
• You are doing something that looks a lot like that for the first maxDepth transactions.

You probably need to adjust your code instead of raising this limit, but if you have a valid need for raising it, please let me know.

You can set this to -1 to disable the check completely, but then if you do actually have an infinite loop, your code will pin the CPU and your single threaded Scala.js app will freeze – not something you want, especially on your users' devices!