SSR?

[leebenson]

I came across rxr from your comment here, and I realised it's almost identical to the approach I was kicking around internally on a new project. Good work!

The one part I haven't figured out yet is server side rendering. Getting RxJS itself to play nicely with SSR is no problem; figuring out a way to deal with per-request context, merging component streams into a single stream and 'awaiting' a ready value before calling ReactDOM.renderToString() is a much deeper rabbit hole to get lost down.

I posted a comment here describing it, and also a similar one in the Recycle lib which provides another nice HOC around handling rx streams.

Would love to hear your thoughts on how to best tackle SSR.

I've been using Promises to date with redial, and that's really easy because resolving to a single value is guaranteed at some stage. Something like that for RxJS that works universally would be awesome.

[dacz]

HI @leebenson, thanks for stopping by rxr.

I use rxr for app behind login, so I have no requirements for SSR so far. I've read your comments elsewhere and looked into your project - very nice idea!

Without deep experience with RxJS and SSR and to some thoughts from your questions:

You mention that you want to wait to just one event with take. I'm not sure about this. Example - loading Author and then loading her books. All done with multiple calls (if you do not use graphQl which I strongly recommend but the problem will still be there). You want to render page with books but you do not need to wait to load the comments for example.

Maybe I'd think about something like "readyToRender" kind of concatenated stream of events that would wait for all signals to be received. And then in the appropriate place within HoCs or Components just signalise this readyState. Seems complicated but it could be as easy as push ok to stream that is concatenated and would resolve to render once all signals are received. For some pages/views may be ok just one signal, for complicated ones more.

This approach is kind of independent of app logic (in the sense that for non SSR it can be stripped away by webpack) and lightweight.

But I may be completely wrong :) SSR done well for more complicated apps is a kind of magic.

Best.

[leebenson]

Thanks @dacz, I really appreciate you taking the time to write back and share your ideas.

I'm currently exploring Recycle which might work for what I'm trying to do. The multiple calls thing can hopefully be solved by resolving a stream of streams, and emitting once each has returned something.

It'll make a big more sense if/when I get this working live. Will let you know how it goes.

Thanks again.