feat: Add two-way computed signals via WritableSignal.map(getter, set… #23370

Artur- · 2026-01-29T15:44:23Z

…ter)

This enables mapping a single field from a record or bean to a separate writable signal that supports two-way bindings. The mapped signal propagates changes back to the parent signal.

Added:

SignalSetter<P,C> interface for immutable update patterns
SignalModifier<P,C> interface for mutable in-place modification
MappedWritableSignal class using parent.update() for immutable values
MappedModifySignal class using parent.modify() for mutable values
WritableSignal.map(getter, setter) default method
ValueSignal.map(getter, modifier) overload for mutable patterns

Example usage with records:
WritableSignal todoSignal = new ValueSignal<>(new Todo("Task", false)); WritableSignal doneSignal = todoSignal.map(Todo::done, Todo::withDone); checkbox.bindValue(doneSignal); // Two-way binding to done property

Example usage with mutable beans:
ValueSignal todoSignal = new ValueSignal<>(new Todo()); WritableSignal doneSignal = todoSignal.map(Todo::isDone, Todo::setDone); checkbox.bindValue(doneSignal); // Two-way binding using in-place modification

Slack thread: https://vaadin.slack.com/archives/C6RAXJATF/p1769700370488139?thread_ts=1769696326.293389&cid=C6RAXJATF

https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

Description

Please list all relevant dependencies in this section and provide summary of the change, motivation and context.

Fixes # (issue)

Type of change

Bugfix
Feature

Checklist

I have read the contribution guide: https://vaadin.com/docs/latest/guide/contributing/overview/
I have added a description following the guideline.
The issue is created in the corresponding repository and I have referenced it.
I have added tests to ensure my change is effective and works as intended.
New and existing tests are passing locally with my change.
I have performed self-review and corrected misspellings.

Additional for `Feature` type of change

Enhancement / new feature was discussed in a corresponding GitHub issue and Acceptance Criteria were created.

…ter) This enables mapping a single field from a record or bean to a separate writable signal that supports two-way bindings. The mapped signal propagates changes back to the parent signal. Added: - SignalSetter<P,C> interface for immutable update patterns - SignalModifier<P,C> interface for mutable in-place modification - MappedWritableSignal class using parent.update() for immutable values - MappedModifySignal class using parent.modify() for mutable values - WritableSignal.map(getter, setter) default method - ValueSignal.map(getter, modifier) overload for mutable patterns Example usage with records: WritableSignal<Todo> todoSignal = new ValueSignal<>(new Todo("Task", false)); WritableSignal<Boolean> doneSignal = todoSignal.map(Todo::done, Todo::withDone); checkbox.bindValue(doneSignal); // Two-way binding to done property Example usage with mutable beans: ValueSignal<Todo> todoSignal = new ValueSignal<>(new Todo()); WritableSignal<Boolean> doneSignal = todoSignal.map(Todo::isDone, Todo::setDone); checkbox.bindValue(doneSignal); // Two-way binding using in-place modification Slack thread: https://vaadin.slack.com/archives/C6RAXJATF/p1769700370488139?thread_ts=1769696326.293389&cid=C6RAXJATF https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

CLAassistant · 2026-01-29T15:44:30Z

All committers have signed the CLA.

Wrap lines exceeding 80 characters to comply with Vaadin code style. https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

The original implementation of two-way computed signals introduced an ambiguous overload: WritableSignal.map(getter, setter) and ValueSignal.map(getter, modifier) had the same arity but different functional interface parameter types. Java's type inference could not always disambiguate between SignalSetter (returns parent type) and SignalModifier (returns void) when using method references or lambdas. Renaming ValueSignal's method from map to mapMutable resolves this ambiguity and makes the distinction clear in the API: map() creates immutable value mappings, mapMutable() creates in-place modification mappings. Fixes #23370 https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

Legioth · 2026-01-30T06:55:33Z

signals/src/main/java/com/vaadin/signals/function/SignalSetter.java

+ * @see WritableSignal#map(SignalMapper, SignalSetter)
+ */
+@FunctionalInterface
+public interface SignalSetter<P, C> {


Not 100% sure about this name but I don't have any good counter proposal right now. The problem is that the callback doesn't itself "set" the value but instead creates a value that the caller will use for setting. So from that point of view, this type is more of a "converter", "creator", or "reducer".

Good point from @Legioth. The name SignalSetter is misleading since the function doesn't set anything - it creates a new parent value given the old parent and new child value.

Some naming alternatives to consider:

Name Rationale

SignalReducer Follows the Redux pattern: (state, value) -> newState

SignalValueReducer More explicit variant

SignalCombiner Combines parent + child into new parent

SignalWithMapper Reflects the withX() method pattern commonly used

SignalValueCreator Creates a new value from parent + child

I think SignalReducer fits well because the signature (P parent, C child) -> P is essentially a reducer function - it takes the current state and a value, and produces a new state. This is a familiar pattern from functional programming.

Would you like me to rename SignalSetter to one of these alternatives?

The "Signal" prefix might be redundant in this context. I'd suggest ValueMerger since it creates a new outer value by merging the new inner value with the old outer value.

Legioth

Haven't looked at the tests yet

Legioth · 2026-01-30T07:54:12Z

signals/src/main/java/com/vaadin/signals/impl/MappedWritableSignal.java

+
+    @Override
+    public SignalOperation<C> value(C newChildValue) {
+        AtomicReference<C> oldChildValue = new AtomicReference<>();


Rather than all the complexity in each method for capturing references to some old value from inside some callback and manually resolving operations, how about just adding support for a map operation on SignalOperation instead?

Added SignalOperation.map() method (SignalOperation.java:119-131):

Transforms the result value using a mapper function
Preserves error propagation
Added CancelableOperation.map() override (CancelableOperation.java:68-92):

Returns a CancelableOperation (not just SignalOperation)
Cancelling the mapped operation also cancels the parent
isCancelled() delegates to parent
Simplified MappedWritableSignal (MappedWritableSignal.java:77-121):

Before (complex with AtomicReference and helpers):

public SignalOperation<C> value(C newChildValue) { AtomicReference<C> oldChildValue = new AtomicReference<>(); CancelableOperation<P> parentOp = parent.update(parentValue -> { oldChildValue.set(getter.map(parentValue)); return setter.set(parentValue, newChildValue); }); return mapOperation(parentOp, oldChildValue); }

After (clean and simple):

public SignalOperation<C> value(C newChildValue) { return parent.update( parentValue -> setter.set(parentValue, newChildValue)) .map(oldParent -> getter.map(oldParent)); }

The replace method still uses AtomicReference because it has conditional success/failure logic that can't be expressed through just map().

Legioth · 2026-01-30T08:01:39Z

signals/src/main/java/com/vaadin/signals/impl/MappedWritableSignal.java

+        AtomicReference<SignalOperation.ResultOrError<Void>> resultRef =
+                new AtomicReference<>();
+
+        CancelableOperation<P> parentOp = parent.update(parentValue -> {


I suspect this could be much simpler like this:

var originalParentValue = parent.peek(); var oldChildValue = getter.map(originalParentValue); if (!Object.equals(oldChildValue, newValue)) { return new SignalOperation<>(new Error<>("Unexpected value")); } return parent.replace(originalParentValue, setter.set(originalParentValue, newValue));

There might be some ABA cases that are rejected in this way even though they could in theory be fine but I don't think that's an issue.

Legioth · 2026-01-30T08:11:55Z

signals/src/main/java/com/vaadin/signals/local/MappedModifySignal.java

+ * License for the specific language governing permissions and limitations under
+ * the License.
+ */
+package com.vaadin.signals.local;


Should be in an impl package since the method creating these instances is defined to return WritableSignal.

Add a map() method to SignalOperation and CancelableOperation that transforms the result value using a mapper function. This allows cleaner composition of operations. Use this new method to simplify MappedWritableSignal's value() and update() implementations, removing the need for manual AtomicReference tracking and custom operation mapping helpers. https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

…nt.replace Use a simpler approach that peeks the current parent value and delegates to parent.replace() instead of using update() with AtomicReference tracking. https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

Move MappedModifySignal from local to impl package since the mapMutable() method that creates these instances returns WritableSignal, making the concrete class an implementation detail. https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

The original implementation of two-way computed signals introduced an ambiguous overload: WritableSignal.map(getter, setter) and ValueSignal.map(getter, modifier) had the same arity but different functional interface parameter types. Java's type inference could not always disambiguate between SignalSetter (returns parent type) and SignalModifier (returns void) when using method references or lambdas. Renaming ValueSignal's method from map to mapMutable resolves this ambiguity and makes the distinction clear in the API: map() creates immutable value mappings, mapMutable() creates in-place modification mappings. Fixes #23370 https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

@see

Update @see reference and example code in SignalModifier to use the renamed mapMutable method instead of the old map method name. https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

github-actions · 2026-01-30T09:17:51Z

Test Results

1 348 files + 2 1 348 suites +2 1h 16m 57s ⏱️ - 1m 22s
9 513 tests +26 9 445 ✅ +26 68 💤 ±0 0 ❌ ±0
9 983 runs +29 9 907 ✅ +28 76 💤 +1 0 ❌ ±0

Results for commit 4944f86. ± Comparison against base commit aa1ddca.

♻️ This comment has been updated with latest results.

Legioth · 2026-02-02T08:42:34Z

signals/src/main/java/com/vaadin/signals/impl/MappedWritableSignal.java

+    @Override
+    public SignalOperation<C> value(C newChildValue) {
+        return parent
+                .update(parentValue -> setter.set(parentValue, newChildValue))


We already discussed this offline but the outcome is non-trivial so it might be good to keep in a comment for future reference.

If we apply the change to the new item, then the user gets the impression that they happened to click immediately after it was changed and then they immediately realize that they can easily undo that accidental change directly from the same UI without having to find the old item in the UI to see if their change ended up there

Legioth · 2026-02-02T08:49:03Z

signals/src/main/java/com/vaadin/signals/operations/CancelableOperation.java

+                return parent.isCancelled();
+            }
+        };
+        result().thenAccept(resultOrError -> {


Duplicated code in SignalOperation. Could be extracted to a protected helper method.

Legioth · 2026-02-02T08:55:02Z

signals/src/test/java/com/vaadin/signals/impl/MappedWritableSignalTest.java

+        }
+    }
+
+    record Pair<A, B>(A first, B second) {


Confusing to have two different test types that have essentially the same structure. Could all tests use the same test type instead?

Legioth · 2026-02-02T08:58:31Z

signals/src/test/java/com/vaadin/signals/impl/MappedWritableSignalTest.java

+    }
+
+    @Test
+    void map_withNullParentValue_handlesGracefully() {


pointless test?

Legioth · 2026-02-02T08:58:59Z

signals/src/test/java/com/vaadin/signals/impl/MappedWritableSignalTest.java

+    }
+
+    @Test
+    void map_stringField_works() {


Pointless test

Legioth · 2026-02-02T09:00:42Z

signals/src/test/java/com/vaadin/signals/local/MappedModifySignalTest.java

+        }
+    }
+
+    static class MutablePair<A, B> {


Redundant and confusing with two separate test classes?

Legioth · 2026-02-02T09:01:51Z

signals/src/test/java/com/vaadin/signals/local/MappedModifySignalTest.java

+        assertFalse(doneSignal.value());
+
+        todo.setDone(true);
+        todoSignal.modify(t -> {


Test makes more sense if the modification is done inside modify instead of before it since that's the recommended way of doing a mutation

Legioth · 2026-02-02T09:38:03Z

signals/src/test/java/com/vaadin/signals/local/MappedModifySignalTest.java

+    }
+
+    @Test
+    void map_stringField_works() {


Seems redundant

Legioth · 2026-02-02T09:43:44Z

signals/src/main/java/com/vaadin/signals/function/SignalSetter.java

+ * @see WritableSignal#map(SignalMapper, SignalSetter)
+ */
+@FunctionalInterface
+public interface SignalSetter<P, C> {


The "Signal" prefix might be redundant in this context. I'd suggest ValueMerger since it creates a new outer value by merging the new inner value with the old outer value.

Extract duplicated result forwarding logic from SignalOperation.map() and CancelableOperation.map() into a protected forwardMappedResult() helper method. Add comment explaining why update() is used in MappedWritableSignal.value() for better concurrent modification behavior.

Rename SignalSetter to ValueMerger with merge() method to better describe its purpose of merging inner values into outer values. Consolidate test types by using single Todo/MutableTodo classes with priority field instead of separate Pair types. Remove redundant tests and fix modify() usage in MappedModifySignalTest.

signals/src/test/java/com/vaadin/signals/impl/MappedWritableSignalTest.java

Use boolean inversion for update() tests instead of adding an int field. Keep Todo/MutableTodo simple with just text and done fields.

sonarqubecloud · 2026-02-02T10:44:53Z

Quality Gate passed

Issues
124 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

claude added 5 commits January 29, 2026 15:59

style: Fix line length formatting issues

63c938a

Wrap lines exceeding 80 characters to comply with Vaadin code style. https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

style: Fix remaining line length issues in test file

93393aa

https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

docs: Clarify javadoc for MappedWritableSignal

d70d305

https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

style: Remove trailing whitespace in WritableSignal

1305d80

https://claude.ai/code/session_01TxPx9BEUzohqox27CLezT5

Legioth reviewed Jan 30, 2026

View reviewed changes

Legioth requested changes Jan 30, 2026

View reviewed changes

claude added 3 commits January 30, 2026 08:22

github-actions bot added the +0.1.0 label Jan 30, 2026

Artur- and others added 2 commits January 30, 2026 10:58

spotless:apply

41ebe7d

fix: Update Javadoc reference to renamed mapMutable method

5c7df2c

Update @see reference and example code in SignalModifier to use the renamed mapMutable method instead of the old map method name. https://claude.ai/code/session_019LonZZA33kKDmk7jCgN7cT

Artur- force-pushed the claude/slack-implement-list-signal-qxPj1 branch from 1c6cf78 to 5c7df2c Compare January 30, 2026 09:02

Artur- marked this pull request as ready for review January 30, 2026 09:02

Artur- added 2 commits January 30, 2026 11:59

spotless:apply

b260b79

Merge branch 'main' into claude/slack-implement-list-signal-qxPj1

72aa1d2

mshabarov added the signals label Feb 2, 2026

Legioth reviewed Feb 2, 2026

View reviewed changes

Legioth requested changes Feb 2, 2026

View reviewed changes

Artur- added 2 commits February 2, 2026 09:49

Legioth requested changes Feb 2, 2026

View reviewed changes

signals/src/test/java/com/vaadin/signals/impl/MappedWritableSignalTest.java Outdated Show resolved Hide resolved

Artur- added 2 commits February 2, 2026 12:32

Merge branch 'main' into claude/slack-implement-list-signal-qxPj1

16e80c3

refactor: simplify test types by removing unnecessary priority field

4944f86

Use boolean inversion for update() tests instead of adding an int field. Keep Todo/MutableTodo simple with just text and done fields.

Legioth approved these changes Feb 2, 2026

View reviewed changes

Legioth merged commit eea90b5 into main Feb 2, 2026
31 checks passed

Legioth deleted the claude/slack-implement-list-signal-qxPj1 branch February 2, 2026 10:56

Name	Rationale
`SignalReducer`	Follows the Redux pattern: `(state, value) -> newState`
`SignalValueReducer`	More explicit variant
`SignalCombiner`	Combines parent + child into new parent
`SignalWithMapper`	Reflects the `withX()` method pattern commonly used
`SignalValueCreator`	Creates a new value from parent + child

feat: Add two-way computed signals via WritableSignal.map(getter, set… #23370

feat: Add two-way computed signals via WritableSignal.map(getter, set… #23370

Conversation

Artur- commented Jan 29, 2026

Description

Type of change

Checklist

Additional for Feature type of change

Uh oh!

CLAassistant commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Legioth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sonarqubecloud bot commented Feb 2, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Additional for `Feature` type of change

CLAassistant commented Jan 29, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading