toposort
Related Doc:
package Schedulers
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.
Events only propagate a value when they are changing, when the system is at rest, events have no values.
Events only propagate a value when they are changing, when the system is at rest, events have no values.
Note: We hide implicit parameters of the API in the documentation. They are used to ensure correct creation, and you normally do not have to worry about them, except if you accidentally call the implicit parameter list, in which cas you may get cryptic errors. This is a scala limitation. We also hide the internal state parameter of passed and returned events.
Value type of the event occurrences.
Source events with imperative occurrences
Source events with imperative occurrences
Type returned when the event fires
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 ...
Time changing value derived from the dependencies.
Time changing value derived from the dependencies.
Type stored by the signal
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.
Source signals with imperatively updates.
Similar to rescala.compat.SignalCompatBundle.Signal expressions, but resulting in an event.
Similar to rescala.compat.SignalCompatBundle.Signal expressions, but resulting in an event. Accessed events return options depending on whether they fire or not, and the complete result of the expression is an event as well.
observers are normale reactives that are configured by a function that converts the value of the input into an ObserveInteract
observers are normale reactives that are configured by a function that converts the value of the input into an ObserveInteract
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.
A signal expression can be used to create signals accessing arbitrary other signals.
A signal expression can be used to create signals accessing arbitrary other signals. Use the apply method on a signal to access its value inside of a signal expression.
val a: Signal[Int] val b: Signal[Int] val result: Signal[String] = Signal { a().toString + b().toString}
Functions to construct signals, you probably want to use signal expressions in rescala.interface.RescalaInterface.Signal for a nicer API.
Functions to construct signals, you probably want to use signal expressions in rescala.interface.RescalaInterface.Signal for a nicer API.
Creates new Vars
Flatten a Signal[Traversable[Event[B]\]\] into a Event[B].
Flatten a Signal[Traversable[Event[B]\]\] into a Event[B]. The new Event fires the value of any inner firing Event. If multiple inner Events fire, the first one in iteration order is selected.
Flatten a Signal[Array[Signal[B]\]\] into a Signal[Array[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Flatten a Signal[Array[Signal[B]\]\] into a Signal[Array[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Flatten a Signal[Event[B]]\] into a Event[B] where the new Event fires whenever the current inner event fires
Flatten a Signal[Event[B]]\] into a Event[B] where the new Event fires whenever the current inner event fires
Flatten a Event[Option[B]\] into a Event[B] that fires whenever the inner option is defined.
Flatten a Event[Option[B]\] into a Event[B] that fires whenever the inner option is defined.
Flatten a Signal[Option[Signal[B]\]\] into a Signal[Option[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Flatten a Signal[Option[Signal[B]\]\] into a Signal[Option[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Flatten a Signal[Signal[B]\] into a Signal[B] that changes whenever the outer or inner signal changes.
Flatten a Signal[Signal[B]\] into a Signal[B] that changes whenever the outer or inner signal changes.
Executes a transaction.
Executes a transaction.
Result type of the admission function
All inputs that might be changed by the transaction
An admission function that may rescala.operator.Sources.Evt.admit / rescala.operator.Sources.Var.admit arbitrary input changes that will be applied as an atomic transaction at the end.
Result of the admission function
transaction(a, b){ implicit at => a.set(5); b.set(1); at.now(a) }
Executes a transaction with WrapUpPhase.
Executes a transaction with WrapUpPhase.
transaction
Flatten a Signal[Traversable[Event[B]\]\] into a Event[Traversable[Option[B]\]\] where the new Event fires whenever any of the inner events fire
Flatten a Signal[Traversable[Event[B]\]\] into a Event[Traversable[Option[B]\]\] where the new Event fires whenever any of the inner events fire
Flatten a Signal[Traversable[Signal[B]\]\] into a Signal[Traversable[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Flatten a Signal[Traversable[Signal[B]\]\] into a Signal[Traversable[B]\] where the new Signal updates whenever any of the inner or the outer signal updates
Methods and type aliases for advanced usages, these are most relevant to abstract over multiple scheduler implementations.