You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More transparent declaration of the conditional event listening.
The warning in the console is now much more probably related to an issue, as the condition will reflect the real state of things.
Discussions:
In the current state, two things can lead to an empty subscription -> falsy/empty event or falsy/empty target
There are real cases when the target is null/empty - and it is related to some problem direct or indirect.
Most likely, there are no known cases when null/empty event was not produced with direct purpose.
Open questions: should we consider the nullable event as an issue to warn about?
If no should we add condition field proposed in bounce of that topic? Discussion result: consider empty even as warning, the issue description is actual
The text was updated successfully, but these errors were encountered:
As an ESL event listener module consumer, I want to be more predictable in subscription handling in case of conditional subscription.
Current state:
works perfectly but is not so readable and produces a console working that the result subscription is empty.
Proposal:
More transparent declaration of the conditional event listening.
The warning in the console is now much more probably related to an issue, as the condition will reflect the real state of things.
Discussions:
There are real cases when the target is null/empty - and it is related to some problem direct or indirect.
Most likely, there are no known cases when null/empty event was not produced with direct purpose.
Open questions: should we consider the nullable event as an issue to warn about?
If no should we add
condition
field proposed in bounce of that topic?Discussion result: consider empty even as warning, the issue description is actual
The text was updated successfully, but these errors were encountered: