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
@abersnaze and I have been exploring a coding style in Rx where more than one data element could be passed via an observable chain. This coding style would be an alternative to existing functionality where one would use subjects and flatMap to tie together two observables. My goal in writing this was to improve composability by obviating the need to close over state in an imperative style. We have an implementation of a subset of Rx operators for a BiObservable which can be subscribed to by a BiSubscriber which takes 2 values by onNext instead of just a single one.
Existing uses:
Need more than one item in an operator function
Combining of an observable with an observable that subscribes to the original
Motivating reasons:
Improve the modularity of Funcs by injecting all inputs
Improve compatibility with Java 8 closures implementation. Observable.map(Func1) can only take a 1 argument closure via Java 8 method references/closures. With a map(Func2) (provided by BiObservable) existing java methods could be used as arguments without creating
By combining observables in this way, developers (and IDE plugins) could reason about dataflow differently. FlatMap loses context of what operators were applied inside the func. BiObservable operators could apply effects without this loss.
Avoids some cases of Func1 instantiation inside a flatmap. Singleton Func2s could be used where you would otherwise have to close over state via constructor calls.
Prevent double subscription when combining two observables which are derived from the same source observable.
Avoiding creation and construction of a Pair class for purposes of onNexting
For instance, when flatMapping an Observable is returned from your function and all operators which resulted in that observable are lost in the context of that function. Static analysis would need to step through the observable returned in order to say anything about the data generated by the topmost observable. BiObservable has operators to apply mutations, reductions, and filters to each operator used on that attached Observable to be declared at the topmost layer of operators. This could enable stronger static analysis where it is used.
Remaining Known Areas for Improvement:
Only the BiObservable has been implemented. Open questions regarding the TriObservable (and above) include: 1) is maintenance feasible, 2) what operators are necessary for conversion.
reduce and scan replace the first or second element in a bivalue (per the chosen operator) leaving the /other/ element untouched. This is useful in that one of the inputs is preserved but clearly not always desirable. But it is flexible. There are some api decisions like this left to be made.
For examples, there is the README and one example of usage in the BiObservableExample.
I will continue development on this external project and welcome feedback. Thanks.
The text was updated successfully, but these errors were encountered:
Request For Review of Multi-Observables link to project
@abersnaze and I have been exploring a coding style in Rx where more than one data element could be passed via an observable chain. This coding style would be an alternative to existing functionality where one would use subjects and flatMap to tie together two observables. My goal in writing this was to improve composability by obviating the need to close over state in an imperative style. We have an implementation of a subset of Rx operators for a
BiObservable
which can be subscribed to by aBiSubscriber
which takes 2 values by onNext instead of just a single one.Existing uses:
Motivating reasons:
Observable.map(Func1)
can only take a 1 argument closure via Java 8 method references/closures. With amap(Func2)
(provided by BiObservable) existing java methods could be used as arguments without creatingFunc1
instantiation inside a flatmap. SingletonFunc2
s could be used where you would otherwise have to close over state via constructor calls.onNext
ingFor instance, when flatMapping an Observable is returned from your function and all operators which resulted in that observable are lost in the context of that function. Static analysis would need to step through the observable returned in order to say anything about the data generated by the topmost observable. BiObservable has operators to apply mutations, reductions, and filters to each operator used on that attached Observable to be declared at the topmost layer of operators. This could enable stronger static analysis where it is used.
Remaining Known Areas for Improvement:
For examples, there is the README and one example of usage in the BiObservableExample.
I will continue development on this external project and welcome feedback. Thanks.
The text was updated successfully, but these errors were encountered: