3 ms·

ok a bit of background: I have been working on my off time for some time now to bring reactive programming to the fore-front of web development, as I think it

ok a bit of background: I have been working on my off time for some time now to bring reactive programming to the fore-front of web development, as I think it best captures the essence of the logic in those domains, which is basically an event/data flow graph. Current languages and tools are built around the traditional sequential flow of a program, and this mismatch makes it pretty hard to properly adopt the paradigm without proper libraries/tooling. RxJS is one of the best such libraries, though it lacks some essential features for being properly used at scale: - It models the flows with inverse event/data flow trees, which though an improvement over the sequential flow still limits how larger flows are described, - It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions). CONNECTIVE is a thin library on top of RxJS that addresses those issues. It is designed to be complementary to RxJS, boosting its flexibility and scalability without limiting its potential. You can read the following entry on the docs section for more info about these issues and how CONNECTIVE addresses them: https://connective.dev/docs/connective-v-rxjs https://connective.dev/docs/connective-v-rxjs

paulddraper 7y ago
I've been using RxJS for a while, but I'm confused about this. I don't doubt you are correct; I'm just having trouble understanding. > It models the flows with inverse event/data flow trees, which though an improvement over the sequential flow still limits how larger flows are described, What does this mean? > It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions). Isn't this just functions? I pass my Observables as arguments and variables, and use pipe() to create transforms. --- Do you have Connective vs vanilla RxJS example to demonstrate? With RxJS your hello world is fromEvent(a, 'input').pipe( map(() => a.value), filter(name => name != 'Donald'), map(name => 'hellow ' + name), ).subscribe(msg => p.innerHTML = msg); EDIT: I see you have https://connective.dev/docs/connective-v-rxjs https://connective.dev/docs/connective-v-rxjs I will look at that.
- lorean_victor 7y ago
  > Do you have Connective vs vanilla RxJS example to demonstrate? Yes, you can find them here: https://connective.dev/docs/connective-v-rxjs https://connective.dev/docs/connective-v-rxjs > What does this mean? It means you (typically) have a few observables being transformed into one (the inverse-tree structure). Reactive flows are in their general-form a directed graph, which can be described as a composition of multiple trees, however that description distances the actual logical model and the description, leading to harder-to-read code. Additionally, the inverse-tree model of RxJS (mostly) enforces order of fully defining the flow as well, which limits your ability of organization of larger reactive flows, specifically across multiple modules (imagine a case where you need to define the beginning and the end of the flow in one module and the middle in some other modules, like a typical http server). > Isn't this just functions? I pass my Observables as arguments and variables, and use pipe() to create transforms. This goes hand-in-hand with the previous question: if all you need to do is to transform some properly defined observables into one transformation observable, then yes they are sufficient. On a more general form though, a re-usable part of a reactive flow would be a sub-graph of a directed graph, which can have multiple inputs and outputs. You can see examples of this across the docs, specifically in the link I mentioned above, or these places: https://connective.dev/docs/node https://connective.dev/docs/node https://connective.dev/docs/composition https://connective.dev/docs/composition > With RxJS your hello world is ... yes naturally in simpler cases where none of the aforementioned apply, there is no difference in using CONNECTIVE over RxJS. this is why CONNECTIVE does NOT mask the full API of RxJS. > I don't doubt you are correct; I'm just having trouble understanding. Well I might as well be wrong actually, thats the main point of these discussions and contemplations, so thanks for asking :)
gitgud 7y ago
> It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions). This is wrong. The "pipe()" operator allows you to reuse parts of an Observable flow in RxJS. For example the following function can be used in many different Observable flows: import { pipe } from 'rxjs/operators'; function checkAuthPipe() { return pipe( doSomething(), runAnotherPipe(), map(out => out.isAuth) ) } This works great at scale too, as pipes can be composed from other pipes... Good work with the library though, like the documentation and the concept behind the framework, we won't know if something's better until we try it.
- lorean_victor 7y ago
  Well pipe(), despite being a great extensibility tool, is not a "flow-reuse" abstraction, as it (mostly) just works as a transformer of (mostly) one observable into another. a reactive flow is a directed graph in general and an inverse-tree in RxJS. of course you can simply re-use parts of the inverse tree using functions from multiple observables to one, and the main issue for this is basically the inverse-tree model limitation, as can be observed in appearance of convention-breaking and uncomfortable pipes such as partition.
nick_ 7y ago
To me, the glaring deficit in RxJS is that it doesn't have an observable collection. The convention to approximate it is `Observable<Foo[]>` which just pushes a whole array change. .NET's ObservableCollection<T> is an example of doing this well.
- lorean_victor 7y ago
  that is an interesting thought. I have not worked with Rx.NET, whats specific features does `ObsevableCollection<T>` have?

paulddraper 7y ago

I've been using RxJS for a while, but I'm confused about this. I don't doubt you are correct; I'm just having trouble understanding. > It models the flows with inverse event/data flow trees, which though an improvement over the sequential flow still limits how larger flows are described, What does this mean? > It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions). Isn't this just functions? I pass my Observables as arguments and variables, and use pipe() to create transforms. --- Do you have Connective vs vanilla RxJS example to demonstrate? With RxJS your hello world is fromEvent(a, 'input').pipe( map(() => a.value), filter(name => name != 'Donald'), map(name => 'hellow ' + name), ).subscribe(msg => p.innerHTML = msg); EDIT: I see you have https://connective.dev/docs/connective-v-rxjs https://connective.dev/docs/connective-v-rxjs I will look at that.

lorean_victor 7y ago
> Do you have Connective vs vanilla RxJS example to demonstrate? Yes, you can find them here: https://connective.dev/docs/connective-v-rxjs https://connective.dev/docs/connective-v-rxjs > What does this mean? It means you (typically) have a few observables being transformed into one (the inverse-tree structure). Reactive flows are in their general-form a directed graph, which can be described as a composition of multiple trees, however that description distances the actual logical model and the description, leading to harder-to-read code. Additionally, the inverse-tree model of RxJS (mostly) enforces order of fully defining the flow as well, which limits your ability of organization of larger reactive flows, specifically across multiple modules (imagine a case where you need to define the beginning and the end of the flow in one module and the middle in some other modules, like a typical http server). > Isn't this just functions? I pass my Observables as arguments and variables, and use pipe() to create transforms. This goes hand-in-hand with the previous question: if all you need to do is to transform some properly defined observables into one transformation observable, then yes they are sufficient. On a more general form though, a re-usable part of a reactive flow would be a sub-graph of a directed graph, which can have multiple inputs and outputs. You can see examples of this across the docs, specifically in the link I mentioned above, or these places: https://connective.dev/docs/node https://connective.dev/docs/node https://connective.dev/docs/composition https://connective.dev/docs/composition > With RxJS your hello world is ... yes naturally in simpler cases where none of the aforementioned apply, there is no difference in using CONNECTIVE over RxJS. this is why CONNECTIVE does NOT mask the full API of RxJS. > I don't doubt you are correct; I'm just having trouble understanding. Well I might as well be wrong actually, thats the main point of these discussions and contemplations, so thanks for asking :)

gitgud 7y ago

> It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions). This is wrong. The "pipe()" operator allows you to reuse parts of an Observable flow in RxJS. For example the following function can be used in many different Observable flows: import { pipe } from 'rxjs/operators'; function checkAuthPipe() { return pipe( doSomething(), runAnotherPipe(), map(out => out.isAuth) ) } This works great at scale too, as pipes can be composed from other pipes... Good work with the library though, like the documentation and the concept behind the framework, we won't know if something's better until we try it.

lorean_victor 7y ago
Well pipe(), despite being a great extensibility tool, is not a "flow-reuse" abstraction, as it (mostly) just works as a transformer of (mostly) one observable into another. a reactive flow is a directed graph in general and an inverse-tree in RxJS. of course you can simply re-use parts of the inverse tree using functions from multiple observables to one, and the main issue for this is basically the inverse-tree model limitation, as can be observed in appearance of convention-breaking and uncomfortable pipes such as partition.

nick_ 7y ago

To me, the glaring deficit in RxJS is that it doesn't have an observable collection. The convention to approximate it is `Observable<Foo[]>` which just pushes a whole array change. .NET's ObservableCollection<T> is an example of doing this well.

lorean_victor 7y ago
that is an interesting thought. I have not worked with Rx.NET, whats specific features does `ObsevableCollection<T>` have?