Module Bonsai_extra_proc

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 action 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 Bonsai.t exactly once.

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

Extends a Bonsai.t by providing a setter effect that can be used to override the returned value. The computation will initially evaluate to the input Bonsai.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.

When passed a `Given model, behaves like value_with_override; takes on the initial value of the given model and has its value overwritten when the callback is scheduled.

When passed a `Computed f model, takes initial value f None. When the callback is scheduled with input i, takes the value f i.

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 Bonsai.t instead of just 'a Bonsai.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.

bonk returns a function which takes an effect and transforms it into the same effect, but it will be enqueued onto the Bonsai action queue instead of running immediately. This can be useful in niche situations where you have a batch of effects that would otherwise interleave and have bad performance behavior.

chain_incr_effects input effects allows you to sequentially schedule effects that depend on a common 'a Bonsai.t, while ensuring that no effect will receive a stale input. This function short-circuits if the input becomes inactive while actions are still being applied.

This is particularly useful for modeling a set of interacting state machines. The outputs of each computation can be collected into a single Bonsai.t, which is then provided to each state machine through an injected action. This util allows model recomputations made in the `i`th state machine to be immediately visible to the apply_action logic of the `i+1`th state machine.

In contrast, just resolving a value with let%arr and scheduling multiple dependent effects with `Effect.Many` will provide all state machines with the state of the world before *any* of them recalculated state.