Class MappedWritableSignal<P,C>
- Type Parameters:
P- the parent signal value typeC- the child (this signal's) value type
- All Implemented Interfaces:
Signal<C>,WritableSignal<C>,Serializable
This enables patterns like mapping a single field from a record or bean to a separate writable signal that can be used with two-way bindings.
- See Also:
-
Constructor Summary
ConstructorsConstructorDescriptionMappedWritableSignal(WritableSignal<P> parent, SignalMapper<P, C> getter, ValueMerger<P, C> merger) Creates a new mapped writable signal. -
Method Summary
Modifier and TypeMethodDescriptionpeek()Reads the value without setting up any dependencies.Sets the value of this signal if and only if the signal has the expected value at the time when the operation is confirmed.update(SignalUpdater<C> childUpdater) Updates the signal value based on the given callback.value()Gets the current value of this signal.Sets the value of this signal.Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, waitMethods inherited from interface com.vaadin.signals.WritableSignal
asReadonly, map
-
Constructor Details
-
MappedWritableSignal
public MappedWritableSignal(WritableSignal<P> parent, SignalMapper<P, C> getter, ValueMerger<P, C> merger) Creates a new mapped writable signal.- Parameters:
parent- the parent signal to map, notnullgetter- the function to extract the child value from the parent, notnullmerger- the function to create a new parent value given the current parent and new child value, notnull
-
-
Method Details
-
value
Description copied from interface:SignalGets the current value of this signal. The value is read in a way that takes the current transaction into account and in the case of clustering also changes that have been submitted to the cluster but not yet confirmed.If the signal implementation supports transactions, then reading the value in a regular (i.e.
Transaction.Type.STAGED) transaction makes the transaction depend on the value so that the transaction fails in case the signal value is changed concurrently.Reading the value inside an
Signal.effect(EffectAction)orSignal.computed(SignalComputation)callback sets up that effect or computed signal to depend on the signal. -
peek
Description copied from interface:SignalReads the value without setting up any dependencies. This method returns the same value asSignal.value()but without creating a dependency when used inside a transaction, effect or computed signal. -
value
Description copied from interface:WritableSignalSets the value of this signal. The result of the returned operation will be resolved with the previous value at the time when this operation was confirmed.- Specified by:
valuein interfaceWritableSignal<P>- Parameters:
newChildValue- the value to set- Returns:
- an operation containing the eventual result
-
replace
Description copied from interface:WritableSignalSets the value of this signal if and only if the signal has the expected value at the time when the operation is confirmed. This is the signal counterpart toAtomicReference.compareAndSet(Object, Object). The result of the returned operation will be resolved as successful if the expected value was present and resolved as unsuccessful if any other value was present when the operation is processed.- Specified by:
replacein interfaceWritableSignal<P>- Parameters:
expectedValue- the expected valuenewValue- the new value- Returns:
- an operation containing the eventual result
-
update
Description copied from interface:WritableSignalUpdates the signal value based on the given callback. The callback receives the current signal value and returns the new value to use. If the original value has changed by the time this change is confirmed, then the returned value is ignored and the callback is run again with the new value as input. This process is repeated until cancelled or until the update succeeds without conflicting changes.The process can be cancelled through the returned operation instance. Note that canceling will only prevent further retries but the change will still be made if the currently running attempt succeeds.
The result of the returned operation will be resolved with the previous value at the time when a successful update operation was confirmed.
Update operations cannot participate in transactions since any retry would occur after the original transaction has already been committed. For this reason, the whole operation completely bypasses all transaction handling.
- Specified by:
updatein interfaceWritableSignal<P>- Parameters:
childUpdater- the value update callback, notnull- Returns:
- an operation containing the eventual result
-