Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add method to Signal's to expose subsciber counts #3229

Open
petersj-ess opened this issue Feb 12, 2025 · 1 comment
Open

Add method to Signal's to expose subsciber counts #3229

petersj-ess opened this issue Feb 12, 2025 · 1 comment
Labels
enhancement New feature or request hilla Issues related to Hilla

Comments

@petersj-ess
Copy link

Describe your motivation

I would like to be able to run a scheduled routine to update a Signals value periodically but only when a client is actually subscribed to the Signal.

Describe the solution you'd like

From what I can see it looks like we would just need to add a getSubscriberCount() method to Signal.java that would just return the size of the Set that contains the subscriber Flux's

Describe alternatives you've considered

No response

Additional context

No response

@petersj-ess petersj-ess added enhancement New feature or request hilla Issues related to Hilla labels Feb 12, 2025
@Legioth
Copy link
Member

Legioth commented Feb 13, 2025

It seems like you are pushing out updates from the server. This is not a use case that we're targeting right now even though we expect to do so at some point in the future. Right now, we're focusing on "collaboration" cases where the updates originate from clients. As you might have noticed, there's not even any API in Signal.java for directly publishing updates from the server even though it can be achieved by abusing some low-level APIs.

getSubscriberCount() might not be the most efficient approach since there might in some cases be thousands of instances to check for each iteration. It would be better if there would be some way of getting an event whenever a signal gets its first subscriber or loses its last subscriber. In a world with signals everywhere, this might be most natural in the form of a signal that has the subscriber count as its value so that you can create a signal effect to receive updates when it changes. I'm also thinking that this "meta" API that isn't directly related to the signal's value should maybe be "hidden" in a helper class somewhere rather than polluting that main Signal class API.

Flux might be a better tool for your use case at least until we have built out the case to better support server-originated updates. You can make your client-side Flux subscriber relay the received updates to a regular client-side signal to keep the same reactive programming model for the UI logic. You can often achieve a quite signal-like experience with the help of Sinks.many().replay().limit(1) on the server since that automatically buffers the latest message and sends it as an initial update to all new subscribers. You can then use sink.currentSubscriberCount() to achieve exactly what you described. Alternatively, you can use EndpointSubscription to define a callback that is run whenever someone subscribes or unsubscribes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request hilla Issues related to Hilla
Projects
None yet
Development

No branches or pull requests

2 participants