Part of #138. Found while writing the Collaboration Kit to Signals migration guide (vaadin/docs#5888).
Real use case
An existing application with a CollaborationBinder on a customer details form, following the documented quick start. It has never declared @Push anywhere, because it never needed to: Collaboration Kit switched push on the first time the form was opened.
The team migrates the form to shared signals. Two agents open the same customer:
- Agent A types a new phone number.
- Agent B's screen does not change. It updates when B next clicks something, or never, if B is only reading.
Nothing throws and nothing is logged. The developer testing the migration in one browser sees correct behaviour, because the user making the change always sees their own change. A second tab open on the same view also looks fine as long as the tester keeps clicking in it.
This is what makes it worth an issue rather than a documentation note: the regression is invisible to exactly the test that a developer runs after migrating a view.
What Collaboration Kit does
Turns push on by itself. When a topic connection activates in a UI with neither push nor polling, ComponentConnectionContext.checkForPush sets PushMode.AUTOMATIC and logs a warning telling the developer to add @Push. On by default, disabled with CollaborationEngineConfiguration.setAutomaticallyActivatePush(false).
What signals have
Nothing. Shared signals never touch the push configuration.
Suggested direction
Either would remove the trap:
- Activate push the way Collaboration Kit does, when a shared signal is first bound in a UI without push or polling.
- Or, if implicit configuration changes are unwanted, log the same warning, so the problem is visible in development.
A warning alone would be enough to make the failure discoverable, which is the part that is missing.
The migration guide now tells readers to add @Push before migrating, while Collaboration Kit is still there to paper over it.
Part of #138. Found while writing the Collaboration Kit to Signals migration guide (vaadin/docs#5888).
Real use case
An existing application with a
CollaborationBinderon a customer details form, following the documented quick start. It has never declared@Pushanywhere, because it never needed to: Collaboration Kit switched push on the first time the form was opened.The team migrates the form to shared signals. Two agents open the same customer:
Nothing throws and nothing is logged. The developer testing the migration in one browser sees correct behaviour, because the user making the change always sees their own change. A second tab open on the same view also looks fine as long as the tester keeps clicking in it.
This is what makes it worth an issue rather than a documentation note: the regression is invisible to exactly the test that a developer runs after migrating a view.
What Collaboration Kit does
Turns push on by itself. When a topic connection activates in a UI with neither push nor polling,
ComponentConnectionContext.checkForPushsetsPushMode.AUTOMATICand logs a warning telling the developer to add@Push. On by default, disabled withCollaborationEngineConfiguration.setAutomaticallyActivatePush(false).What signals have
Nothing. Shared signals never touch the push configuration.
Suggested direction
Either would remove the trap:
A warning alone would be enough to make the failure discoverable, which is the part that is missing.
The migration guide now tells readers to add
@Pushbefore migrating, while Collaboration Kit is still there to paper over it.