Spring @HillaScope or similar mechanism to scope fullstack signals

[berndhopp]

My motivation

It is not clear to me wether it is planned to have some sort of scoping for fullstack signals. The API looks promising, but when I can't use them scoped to a per-user context, they're largely useless to me.

Describe the solution you'd like

The code I'd like to write would look like this:

@HillaSessionScope
public class MyUserNameSignal extends Signal<String> {
...
}

[Legioth]

Not sure I understand the use case. The user name is not supposed to change other when logging in or out, and the client is otherwise also aware of those operations so you wouldn't need a signal for that.

[berndhopp]

Username is just a placeholder for 'session-specific data' here. You may replace it with a users self-description ( aboutMe ), which could obviously be changed during a session.

Currently, there is no way to represent aboutMe with fullstack signals, because they cannot be scoped to a session. IMHO if Vaadin wants people to use fullstack signals, these must be made scopeable or they won't fly.

[Legioth]

I guess what you can do is to create a holder bean that is session scoped and store the signal in that bean?

@SessionScope
public class UserSignals {
  private Signal<String> userName = ...;
  public Signal<String> getUserName() {
    return userName;
  }
}

Directly scoping the signal might become complicated due to the way session scoped beans are implemented by Sping as a proxy instance when it's injected into the application scoped service class. That proxy has the potential to cause lots of problems for something like a signal.

[berndhopp]

Yes, that was also the solution that grok was suggesting to me, but it feels somewhat cumbersome because in my view there is just too much boilerplate, so it's neither intuitive nor obvious ( as in 'obvious what's to do' ).

My suggestion would be to introduce an annotation @ClientExposed, which can be attached to classes derived from Signal<>. Such classes are then eagerly instantiated once per session and get exposed on the client by easy-to-use generated code, similar to endpoints.

Let me try to juxtapose the current solution with what I'm envisioning:

current solution ( not tested )

server

@SessionScope
public class UserSignals {
  private Signal<String> userName = ...; // btw., is it save to initialize the signal here? And how?
  public Signal<String> getUserName() {
    return userName;
  }
}

@Endpoint
class MyEndpoint {
    private final UserSignals userSignals;

    ...

    public Signal<String> userNameSignal() {
      return userSignals.getUserName();
    }
}

client

//also not obvious what is the best place for this export when the signal is shared across components
export const userNameSignal = MyEndpoint.userNameSignal();

my suggestion

server

@ClientExposed
public class UserNameSignal extends Signal<String> {
}

client

import userNameSignal from 'generated.somewhere'

// userNameSignal is an auto generated singleton on the client side, similar to the endpoints
<div>my name is {userNameSignal.value}</div>

<Button onClick={() => userNameSignal.value = 'fooBar'}>
</Button>
 

I'm sure there are technical challenges with my suggestion, I can only tell you from a personal perspective that the latter code strikes me as more appealing to developers which aren't using Vaadin already.