I am interested in Signals as a way to eliminate my reliance on the event bus and component lifecycle events.
We are told that Signals begin operation when a Component is attached, and are removed when a Component is detached.
But onAttach and onDetach events are terribly unreliable. Resynchronization triggers, browser refresh with F5, adding a child to a parent while the parent is inside a beforeEnter method does not call the onAttach of the child (but should), etc, mean we all have to program defensively around the issue. In fact, nothing in my application relies on onAttach/onDetach because I have learned the hard way that it cannot be trusted.
Can I, in some hopeful and not naive way, hope that Signals will alleviate the headache?
Signals rely on listening to attach and detach events to avoid leaking memory in case the signal lives longer than the component. You have exactly the same challenge if you manually listen to an event bus (unless you use a reference queue to detect when to stop listening).
Resynchronization leads to havoc in any stateful situation. It’s “game over” regardless of attach and detach events in such cases. We did some serious work to improve how those cases are handled in Vaadin 24.7.
Browser refresh means that new instances are created (unless using @PreserveOnRefresh). In some cases, the old instance gets detached only after a timeout but that shouldn’t have any significant impact on correctness specifically for signals.
What remains is potential bugs in the attaching and detaching logic in specific edge cases. We should fix such cases rather than expecting application logic to work around them. The specific examples you linked is related to navigation lifecycle methods whereas onAttach and onDetach seem to be in order since the existing instance remains attached. This should be fine with regards to signals since the bindings that were active prior to navigation remains active also after navigation.