Enables reading of the current value during admission.
Enables reading of the current value during admission. Keeps track of written sources internally.
Base implementation for reactives, with Derived for scheduling, together with a ReName and containing a State
Enables the creation of other reactives
Enables the creation of other reactives
A reactive value is something that can be reevaluated
A reactive value is something that can be reevaluated
Essentially a kill switch, that will remove the reactive at some point.
Essentially a kill switch, that will remove the reactive at some point.
Removes the reactive instead of its next normal reevaluation.
Removes the reactive instead of its next normal reevaluation. This makes use of the fact, that all reactives are technically dynamic reactives, and removing incoming dependencies is always kinda safe, as long as we are sure we no longer care!
Provides the capability to look up transactions in the dynamic scope.
Provides the capability to look up transactions in the dynamic scope.
User facing low level API to access values in a dynamic context.
User facing low level API to access values in a dynamic context.
Encapsulates an action changing a single source.
Encapsulates an action changing a single source.
An initializer is the glue between that binds the creation of the reactive from the operator and scheduler side together.
An initializer is the glue between that binds the creation of the reactive from the operator and scheduler side together. The operator provides the logic to wrap a state and the scheduler provides the implementation of that state. This is where the two are joined. After that, the new reactive may have to be initialized.
If no Fitting Ticket is found, then these implicits will search for a DynamicScope, creating the reactives outside of any turn.
If no Fitting Ticket is found, then these implicits will search for a DynamicScope, creating the reactives outside of any turn.
Records side effects for later execution.
Records side effects for later execution.
Source of (reactive) values.
Source of (reactive) values.
Common macro accessors for rescala.operator.SignalBundle.Signal and rescala.operator.EventBundle.Event
Common macro accessors for rescala.operator.SignalBundle.Signal and rescala.operator.EventBundle.Event
return type of the accessor
ReevTicket is given to the Derived reevaluate method and allows to access other reactives.
ReevTicket is given to the Derived reevaluate method and allows to access other reactives. The ticket tracks return values, such as dependencies, the value, and if the value should be propagated. Such usages make it unsuitable as an API for the user, where StaticTicket or DynamicTicket should be used instead.
Result of a reevaluation
Result of a reevaluation
Scheduler that defines the basic data-types available to the user and creates turns for propagation handling.
Scheduler that defines the basic data-types available to the user and creates turns for propagation handling. Note: This should NOT extend DynamicScope, but did so in the past and there are too many tests that assume so ...
In case you wondered why everything in REScala is in these weird bundle traits, this is why.
In case you wondered why everything in REScala is in these weird bundle traits, this is why. The ReSource below depends on some abstract state, which is defined by the concrete scheduler implementations. As basically everything else references ReSources, everything must be bundled together. This is good for users, because they get strong guarantees about the used correctness, and the API is still OK. Its terrible for us, because the Scala Incremental compiler does not really work anymore.
User facing low level API to access values in a static context.
User facing low level API to access values in a static context.
A transaction (or maybe transaction handle would be the better term) is available from reevaluation and admission tickets.
A transaction (or maybe transaction handle would be the better term) is available from reevaluation and admission tickets. That is, everywhere during a transaction, you can read reactives, but also create them. The reading values is core to any reactive propagation. But creating reactives using the Initializer is a liability to the scheduler, but a superpower to the operators. Its a classical tradeoff, but it would be better to not make this choice by default, that is, reactive creation should be limited such that we can experiment with schedulers that do not have this liability.
As reactives can be created during propagation, any Ticket can be converted to a creation ticket.
As reactives can be created during propagation, any Ticket can be converted to a creation ticket.