package bonsai

with_inject_fixed_point allows an injection function produced as the result of a computation to be used as the input of that same combination. This "tie-the-knot" operation is legal because actions are scheduled independently of computation evaluation, allowing us to break what seems like a dependency loop.

However, it is important that the input injection function isn't the same one that is returned by the computation (or even a component of the returned injection function). If that happens, an action being triggered will cause an inifinite loop to occur in the aciton scheduler.

with_self_effect gives access to an effect which produces the output 'a within the body of f. This can be useful if you'd like to install an effect handling function on f whose logic depends on its current value.

pipe constructs a pipe of a and returns a pair containing an injection function that enqueues items and an Effect that dequeues them.

As its name implies, exactly_once runs the event passed in via Value.t exactly once.

As its name implies, exactly_once runs the event passed in via Value.t exactly once. The return value is stored and returned. None is returned while the effect is executing.

Extends a Value.t by providing a setter effect that can be used to override the returned value. The computation will initially evaluate to the input Value.t. Once the returned overriding effect is dispatched at least once, the computation will evaluate to the override value provided. The effect can be scheduled more than once to update the override. Use with Bonsai.with_model_resetter in order to revert the override.

This function is identical to Bonsai.state_machine0 except that the default_model is initially unset, but can be computed or defaulted to a dynamic value.

This means that before an apply_action occurs, the model can change out from underneath the state machine as the default_model value changes. If this is undesirable, you may want to freeze the default_model first.

Read the docs for state_machine0_dynamic_model. This one has an extra 'input value that can be taken into account when the apply_action is invoked.

The analog of Bonsai.state, but with a dynamic model. Read the docs for state_machine0_dynamic_model

Id_gen builds a component which generates unique identifiers by starting at 0 and incrementing by one every time that the effect is called.

mirror is used to reflect state back and forth between locations. Frequently this will be used to back up a components model in a more persistent form of storage, such as the URL, or local-storage.

The gist of this combinator is that if you have two states that you'd like to be synchronized, you can feed the "current value" and "set value" functions for both states into mirror and they'll automatically be kept up to date. Either of these can be backed by any kind of structure, but there are some important differences in their symmetry.

When the component is first loaded, store has priority, so if the values are different, store wins, and interactive has its value "set". From that point on, if either incoming value changes, the opposite setter is called. In the case that both store and interactive change at the same time, the tie is broken in favor of interactive, and store_set is called.

mirror' is like mirror, but the incoming values have the type 'a option Value.t instead of just 'a Value.t. When a value is changed and its new value is None, we don't propagate it to the other setter.

with_last_modified_time applies a cutoff to the input value and takes a note of the last time the value did not cutoff (in other words, the last time it was changed).

Whenever the returned computation is activated, the "last time modified" value will be reset to the current time.

is_stable indicates whether the input value has changed (according to equal) in the past specified time span.

value_stability determines whether the current value has changed recently, and also keeps track of the most recent stable value.