Skip to content

shared-signals.adoc: Replace ValueSignal with SharedValueSignal#5635

Open
DarioViva42 wants to merge 1 commit into
vaadin:v25.1from
DarioViva42:patch-2
Open

shared-signals.adoc: Replace ValueSignal with SharedValueSignal#5635
DarioViva42 wants to merge 1 commit into
vaadin:v25.1from
DarioViva42:patch-2

Conversation

@DarioViva42

Copy link
Copy Markdown
Contributor

This documentation describes the usage of Shared Signals. So it is really confusing and probably a mistake, that in some of the examples Local Signals are used.

This documentation describes the usage of Shared Signals. So it is really confusing and probably a mistake, that in some of the examples Local Signals are used.
@cla-assistant

cla-assistant Bot commented Jun 5, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@cla-assistant

cla-assistant Bot commented Jun 5, 2026

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@DarioViva42

Copy link
Copy Markdown
Contributor Author

Also what I also find pretty Strange that there is a Shared Signal SharedNumberSignal but not a Local Signal NumberSignal. There are also similar discrepancies in this regard. It's especially strange because in an earlier edition of Signals the class NumberSignal existed. Is there a migration guide for people that used the Signals as they were in the early days?

Also we get the following error:

An asynchronous signal can only share transaction with computed signals and other asynchronous signals that belong to the same tree.

Beforehand this code worked.

We had two Signals that we created with the IN_MEMORY_SHARED SignalFactory. and then we updated the two signals with Signal.runInTransaction. This worked but now it does no longer.

Where should such questions be asked. On some documentation pages you can comment. Like https://vaadin.com/docs/latest/components/avatar. But on the documentation https://vaadin.com/docs/latest/flow/ui-state/shared-signals this does not work, which is kind of strange.

@Legioth

Legioth commented Jun 8, 2026

Copy link
Copy Markdown
Member

Thank you for pointing out the inconsistency in the documentation! At the same time, the correct fix isn't as easy as just replacing ValueSignal with SharedValueSignal. That's because SharedValueSignal is intended for sharing state between multiple users whereas two of the three examples that you suggest changing are sharing state between different parts seen by the same user. SharedValueSignal can be used in that case but it's overkill and will lead to some other trade-offs. We should instead revise the documentation to more clearly point out the conceptual difference between single-user sharing and multi-user sharing.

Also what I also find pretty Strange that there is a Shared Signal SharedNumberSignal but not a Local Signal NumberSignal.

There's no need for a dedicated local signal type for numbers. You can just as well use ValueSignal instead. In the shared case, there's a need for an atomic incrementBy operation whereas the local case works just as well with signal.update(x -> x + 1). Additionally, SharedNumberSignal is backed by JSON serialization and thus using a 64-bit floating point number which makes it convenient to have helper methods for accessing the value as an int. This is not necessary when using ValueSignal<Integer>.

Also we get the following error:

An asynchronous signal can only share transaction with computed signals and other asynchronous signals that belong to the same tree.

This was one of the main reasons we decided to introduce the split between "local" and "shared" signals. The shared signals are designed to eventually support synchronizing state across a cluster. One of the trade-offs in that case is that different signals might be "owned" by different nodes in that cluster which means that it's not possible to have an atomic transaction that covers both of them. You can force both signals to be "owned" by the same node by creating them as child signals of the same root signal:

SharedNodeSignal root  = new SharedNodeSignal();
ValueSignal<String> first = root.insertChildWithValue("first", ListPosition.last()).signal().asValue(String.class);
ValueSignal<String> second = root.insertChildWithValue("second", ListPosition.last()).signal().asValue(String.class);

It's now possible to use both first and second in the same transaction.

On some documentation pages you can comment.

That's a configuration issue on our side. Thanks for pointing out.

In general, the kinds of questions you present here are still more appropriate for our discussion forum at https://vaadin.com/forum/.

@Legioth

Legioth commented Jun 8, 2026

Copy link
Copy Markdown
Member

I created #5636 for revising the whole structure of the documentation related to shared signal.

@DarioViva42

Copy link
Copy Markdown
Contributor Author

@Legioth Small correction in your code snippet:

SharedNodeSignal root  = new SharedNodeSignal();
SharedValueSignal<String> first = root.insertChildWithValue("first", ListPosition.last()).signal().asValue(String.class);
SharedValueSignal<String> second = root.insertChildWithValue("second", ListPosition.last()).signal().asValue(String.class);

This might be confusing for others reading this in the future. But asValue returns SharedValueSignal and not ValueSignal

@DarioViva42

Copy link
Copy Markdown
Contributor Author

@Legioth

I have also added an new forum entry. The code that used to work still does not, but I get another exception now.

https://vaadin.com/forum/t/sharednumbersignal/179566

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants