rescala.core

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 ReInfo and containing a State

Enables the creation of other reactives

A reactive value is something that can be reevaluated

Essentially a kill switch, that will remove the reactive at some point.

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.

User facing low level API to access values in a dynamic context.

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. 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.

Records side effects for later execution.

Provides names for dynamic dependencies based on their definition position to allow easier debugging

Source of (reactive) values.

Common macro accessors for rescala.operator.SignalBundle.Signal and rescala.operator.EventBundle.Event

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

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 ...

As reactives can be created during propagation, any Ticket can be converted to a creation ticket.

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. 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.