Best Practices for Signal Ownership and Propagation

Flow
1

I’m exploring Vaadin Signals in a Flow application and I want to make sure I follow best practices regarding ownership, lifecycle, and propagation. I understand that Signals can be used to inform the UI about backend state changes, but I’m unsure about the most appropriate way to manage and share them between UI classes and “Service” classes.

  1. Should I create global application-wide signals via SignalFactory.IN_MEMORY_SHARED in the UI and the Backend service, or is it better to manage signals as Spring beans? Or maybe member variables in Service classes with a getter for the UI?
  2. For signals that are UI/session-specific, is it recommended to use @UIScope Spring beans, or pass them via constructors to the views/components?
  3. Who should “own” a signal — the backend service that updates it, or the frontend/UI component that binds to it?
  4. Are there recommended patterns for when a signal represents shared state vs local component state?

I’d love to hear how others structure their Signals in a Vaadin Flow project.

Thanks in advance!

2

The Signals feature is still in formation, so that naturally means that what ever is considered the “best practice” is in formation too. Any new API we add, may tilt it to some direction.

But shortly, if you use Spring, yes then I would use Spring scopes to control the scope of the Signal. The system is designed so that singleton i.e. application wide signals are possible and they support Push updating of the UI. This means that you can have differently scoped Signals in your application.

I would still consider Signal part of the UI state logic. Say if I have backend module, I would not add Vaadin depenency to it. So Signals would sit between service and UI presentation layer. One way to put is to use “view model”.

We would be interested also to hear comments on these questions from those who have implemented prototype apps and PoCs using Signals and how they feel about this, and how they fit their preferred architectures.

1 Like