You've sent me down a really interesting rabbit hole as someone who is trying to move away from just writing and understanding how React works. Can you explain a little more why this felt worth pursuing? I'm interested in what sorts of advantages this could have.

Sure! Some ideas come to mind:

1. Async and conditional effects without hopping component boundaries with switchMap

2. React.Context ritual vs oneliner `pipe(shareReplay)` - this is easily the most useful thing, in lines of code alone

3. React is used shallowly for jsx and html, and rxjs is used for events and state and quite literally everything not writing to the dom.

4. Lazy by default, no need for suspense bc it's inherit property of observables.

5. Merge and combineLatest give you algebraic tools for constructing your logic instead of stringing components down a subtree

6. Scan but that's just inline redux reducer but I use it all the time

7. Observables are on standards track for HTMLElements in browser. - element.when('click').map/filter/takeUntil etc.

I view react as promises--. You have to do wildly hacky things using custom API ideas that change between majors, can only use sync functions, yet all your logic is async. It's like the function coloring problem on steroids.

The maiden voyage of my blog will be soon, it's first big write up will be the test page for this jsx transform, then I'm gonna be writing a field guide for how to translate between react and rxjs.

Incredibly good reference imo: https://dev.to/mfp22/rxjs-can-save-your-codebase-49fi

Tried to make this concise but I'm on mobile