Signals v/s EventBus

Flow
1

In the past, whenever I needed to update the UI state, after a change in some @Entity, I relied on EventBus using ComponentEvent

e.g. Whenever the user information was changed in the ProfileView, the MainView would get notified and the avatar, display name etc would get updated

//Base custom event
@Getter
public abstract class MyEvent extends ComponentEvent<Component> {

    public enum Type {
        CREATE, UPDATE, DELETE
    }

    private final Type type;

    public MyEvent(Component source, Type type) {
        super(source, true);
        this.type = type;
    }
}

//Custom event
@Getter
public class UserEvent extends MyEvent {

    private final User user;

    public UserEvent(Component source, User user, Type type) {
        super(source, type);
        this.user = user;
    }
}

//MainView
@Override
    protected void onAttach(AttachEvent attachEvent) {
        super.onAttach(attachEvent);
        this.userRegistration = ComponentUtil.addListener(UI.getCurrent(), UserEvent.class, event -> {
            //User updated
            if (MyEvent.Type.UPDATE.equals(event.getType())) {
                this.currentUser = event.getUser();
                this.avatar.setName(this.currentUser.getDisplayName());
                this.menuDisplayName.setText(this.currentUser.getDisplayName());
                this.instituteNameTitle.setText(currentUser.getInstitute().getDisplayName());
            }
        });
    }

    @Override
    protected void onDetach(DetachEvent detachEvent) {
        super.onDetach(detachEvent);
        this.userRegistration.remove();
    }

Now, from what I understand, Signals is the recommended way moving forward.
What advantages/extra features does Signals offer, over ComponentEvent?

Thank you

2

I would not yet claim it is the definitive way for everything, and it is still being built and evolving. But yes, there is overlap on your use case, and if I would be building an application from the scratch I would consider Signals as candidate for such case. However if you have big application under maintenance I would not haste to refactor it now yet.

Also it is notable to mention that ComponentEvent is not going to go away, it is a fundamental low layer functionality and some portion of Signals implementation is using it as well.

Signals can be used also as singletons for application scope updates. Signal also is a data holder, i.e. state management mechanism. ComponentEvent is decoupled from data. Therefore Signal is encapsulating more logic in opionated manner, and reduces amount of code you need to write if you like paradigm. Signals have also encapsulate Push updates of the UI when required (as singleton Signals are supported). We envision also adding API how to connect Signals to cluster wide event busses later.

1 Like
3

My problem with signals is that it adds another concept.

My applications are often event driven and also having events in the UI made it simple to understand and consistent.

4

At the same time, it also removes one concept since you will no longer need UI.access for updates that are triggered from outside the UI itself.

5

An event is “this happened right now”. A signal is “this is the current state based on what has happened”.

Events are very generic whereas signals are designed specifically for updating the UI. In your case, using signals would remove the need to declare a separate UserEvent type and it would remove the need to handle attach and detach events. Your entire example could be reduced to just three lines of code:

this.avatar.bindName(currentUserSignal.map(User::getDisplayName));
this.menuDisplayName.bindText(currentUserSignal.map(User::getDisplayName));
this.instituteNameTitle.bindText(() -> currentUserSignal.value().getInstitute().getDisplayName());

(The bindName and bindText methods don’t exist yet but you can already do similar but slightly longer one-liners with ComponentEffect.bind.)

1 Like