-
Notifications
You must be signed in to change notification settings - Fork 432
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
Signal
adaptivity.
#163
Comments
The idea definitely makes sense. It's reminiscent of #140. But it's hard to know for sure what this will look like. |
Sadly, after a second thought, the adaptivity cannot be propagated in all cases, as we have many operators being stateful and events should not be dropped at all for them. Only stateless operators like |
We usually have lots of
Signal
s sticking around. But not all of them is always in use at any point — by "in use", I mean aSignal
graph as a whole is not observed by anyone. Some can be freed in this circumstance, e.g.Notification
signals if not transformed, but generally they cannot.Let's say
reactive.trigger(for: selector)
— it creates aSignal
that would stick around forever until the object is gone. So it still costs a bit CPU time even if it gets no observers. ConvenienceSignal
s, e.g.Action.values
,Action.errors
, also fall into this category.Inspired by CwlSignal's notion of activation, we might optimize this by having adaptive
Signal
s.Signal
adaptivityWhat does adaptivity mean to a
Signal
?It means a
Signal
would adapt to the situations that the event delivery would not yield an substantial effect, and would deactivate accordingly. Deactivation means all subsequentvalue
events received are silently dropped until reactivation.Deactivated
Signal
can be reactivated simply by attaching an observer.Currently,
value
events would be going through the entire event delivery routine — and all the derivedSignal
s — even if eventually it would reach no one.Limited propagation
Edit: While
Signal
adaptivity is designed to cater aSignal
graph, only statelessSignal
s should propagate the deactivation. In other words, adaptivity is an opt-in.For example, stateful operators like
combineLatest
rely on being always informed of the latest value, and therefore should not inform its upstream of its deactivation at all.How would it work?
First, we would have to make a distinction between the types of
Signal
observers:Signal
's descendants.With that, we would define that a
Signal
should deactivate if it has:Similarly, we would define that a
Signal
should reactivate if:This requires a reversed channel to the event flow, similarly to producer interruption.
Is it breaking?
Apparently yes. But not for the general crowd of ReactiveSwift. It affects the same group of audience as the new
Signal
lifetime semantic.The introduction of
Signal
adaptivity would further restrict theSignal
semantic:Signal
graph does not have any external observer, injected side effects (e.g.on
) would not be evaluated.How does it affect the public API?
It is expected not to affect the public API at all, except for the bit about lifetime we've just mentioned.
Synergy with #144 (Remove
interrupted
)With a real reversed channel, #144 may share it with
Signal
adaptivity, and eliminate the workarounds ofstartWithSignal
.The text was updated successfully, but these errors were encountered: