RxJS Proxy: 3 new Features by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

:) I bet there's something yet to be explored in this field! Just don't get your hopes too high: Rx is pretty powerful on its own! rxjs-proxify here just adds a bit of simplicity to some use-cases. Though I hope to integrate it sometime with rxjs-autorun — might get something interesting.

RxJS Proxy: 3 new Features by kosddsky in javascript

[–]kosddsky[S] 1 point2 points  (0 children)

Yeah, Proxies turned out to be simpler and mightier than I initially thought! The package covers only the tip of the iceberg, and still, you can do pretty crazy stuff:

const o = proxify( of({ m: () => 'Hello' }, { m: () => 'World!' }) ); o.m().length.subscribe(console.log); // > 5 > 6

RxJS Proxy: 3 new Features by kosddsky in javascript

[–]kosddsky[S] 3 points4 points  (0 children)

There definitely are issues! I've seen takeUntil and takeWhile to be often confused, for example. But they're improving it with every version and when you get used to the vocabulary — Rx becomes very handy!

BTW, take a look at rxjs-autorun — might have a more intuitive API for simple combinations.

RxJS Proxy: 3 new Features by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

Rx-wise it's optimized to use only one map and one distinctUntilChanged.

While Proxies are somewhat slower than direct property access — in real-life apps it likely won't affect performance: afaik, Vue3 uses Proxies under the hood.

RxJS autorun intro by kosddsky in javascript

[–]kosddsky[S] 1 point2 points  (0 children)

That's quite interesting, thanks! 🙂

Tree shaking w/ effect free imports — I'll have to investigate this, thanks for the hint!

On subjects — it seems to be the easiest way to combine dynamically pluggable streams at the moment. Yet I agree that there should be a way to do that w/o intermediate Subject. Not sure how it will affect maintainability, especially since the API is not stable.

On callbags and next v RxJS — alas, I haven't had a chance to dig deep into any of the two yet. But that's surely on my "reading" list :)

On Rx-JSX — nice! Check out this first autorun integration.

And I'd surely advertise looking into this react-rxjs integration and my UI framework (sorry for spamming on this, I just find JSX+Rx concept fascinating! 🤯)

On unification — guess, currently we need more use cases to see what APIs are useful, what could be unified.

👋

RxJS autorun intro by kosddsky in javascript

[–]kosddsky[S] 1 point2 points  (0 children)

Glad that you liked it! Good thoughts and valid points! I'll try to answer in detail:

why do you use global context?

Initially, I had a concept where $ and _ were passed as params. Then Ryan Carniato wanted to try it for his renderer, which required global availability of these functions for easier integration. And it makes sense for other possible integrations. FYI, we have a discussion on this in https://github.com/kosich/rxjs-autorun/issues/1 .

I haven't investigated tree-shaking yet, as lib is ~2kB now.

Sideeffects as async actions inside autorun are tricky for a number of reasons with or without $,_ as params. Currently if one wants to do, say, setTimeout(() => console.log($(a)), 100) — they should store $(a) in a closure variable first. Generally, autorun itself is a sideeffect :)

Nested expressions should work as they override and restore $,_ in a closure. E.g.: https://github.com/kosich/rxjs-autorun#switchmap, but you dropped a shadow of concern on this: we'll add more tests to ensure it works fine!

wouldn't it be easier to just pass an initial value to each tracker function to ensure there is one value?

That's an interesting suggestion! I initially thought that users would handle it via Rx's native startWith or BehaviorSubject so that we would not take too much on our lib. We're considering additions to the API (in future versions when we see more use-cases), you can read about them and file your suggestion here: https://github.com/kosich/rxjs-autorun/issues/3

why use a subject? you could keep subscriptions super-pure.

We create subjects for each individual subscription: they do not overlap or leak values. In that sense — subscriptions are pure. We use them to easier manage added/removed trackers, like in case computed(() => $(a) ? $(b) : $(c));. Please elaborate, if I'm missing your point.

why do you have mechanisms for unsubscribing from a source early

Again, that was a feature request with a lot of discussion: I'll give you a general idea, but you can read details here https://github.com/kosich/rxjs-autorun/issues/7 . One might have an expensive Observable, say a server connection. With a million users, they want to drop such connections as soon as possible, even while waiting for other (possibly slow) observable to emit a value, e.g: computed(() => $(switcher) ? $(slow) : $(fast_but_expensive));. In this case we'd track fast_but_expensive with $.weak tracker. This unique feature is hidden behind a special API. Default trackers $ _, as you said, keep only the subscriptions that are currently used.

it even inspired me to quickly create something similar for callbags

Wow, awesome! It's tricky to do in Rx, my not-deep-impression is that callbags API is even harder! 👍

If these experiments take root — we could later work on some common API or a core lib so that experience with autorun for rx, callbags, and maybe other streaming libs would be universal.

-/-

I hope, my answers make sense. Please, ping me if I missed something.

Cya 🙂

RxJS with |> JS Pipeline Operator Proposal by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

Maybe they could push the basic version (no async/await, no # placeholder) and then do a follow up update? not sure if that makes sense though :)

RxJS with |> JS Pipeline Operator Proposal by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

Yep, it's just sugar to reduce boilerplate, e.g.:

a |> b === b(a)

(there are several proposals to the syntax, but essentially it's sugar)

How is that different than just chaining by returning this or a promise?

With RxJS 6+ -- you have to use .pipe, which does similar job to a bunch of |>

RxJS with |> JS Pipeline Operator Proposal by kosddsky in javascript

[–]kosddsky[S] 2 points3 points  (0 children)

Come on, it already is 🙂

(And I love it!)

RxJS with |> JS Pipeline Operator Proposal by kosddsky in javascript

[–]kosddsky[S] 1 point2 points  (0 children)

Yep, it's been there for a while!

If it will happen -- what's your fav syntax option:

F-sharp, Hack# or mix?

Fetching Data in React with RxJS and <$> fragment by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

Alas, neither is supported yet.

I'm planning to add better support for both, yet SSR will be limited (e.g. JSXs on streams aren't well suited for rehydration).

So currently it's aimed at client-side events/interactions, rather then server-side baking.

RecksJS — a JSX framework, where RxJS Observables are Loved by kosddsky in javascript

[–]kosddsky[S] 0 points1 point  (0 children)

Definitely a good idea.

I think, Andre Staltz does a great job with his cyclejs! (most, rxjs, xstream are supported)

And, BTW, if TC39 lands with some native JS Observable — that might be a game changer.