`<Subscribe>` without `source$` does not seem to work as advertised about react-rxjs

[voliva]

You can also do bind(someObservable$.pipe(startWith("")))

[jyssh]

That works! Thank you for this library and your prompt response.

[voliva]

That same paragraph starts with a key point:

If you don't give it a default value, you will need to make sure that observable has a subscription active before the Component that uses that hook is called.

The behaviour that <Subscribe> has regarding auto-subscribing only applies for those states that don't have a default value.

In cases where the state does have a default value, the component doesn't require an active subscription to that state during rendering. Consequently, <Subscribe> will not subscribe to it.

If you do require an open subscription for that state, you can make use of the source$ parameter, as you've already noted.

[jyssh]

Ok. My use case is a multi-step (or multi-"page") form, throughout which I need to keep several state-streams - each associated with an input - alive.

However, the components subscribed to those state-streams would come and go as the form changes its step/page. But I would like to those state-streams retain their values and not reset to 0 (when the subscriptions to them reach 0).

I see <Subscribe> as a way to keep subscriptions to those streams alive while the page under the <Subscribe> keep switching.

Is this way of using <Subscribe> correct?

If not, then is there another way to achieve my purpose?

[jyssh]

If you do require an open subscription for that state, you can make use of the source$ parameter, as you've already noted.

If <Subscribe source$> is the only way, then in order to keep more than 1 state-streams alive, I imagine I would have to merge those streams into one, and use that merged stream as the source$. Correct?

[voliva]

If <Subscribe source$> is the only way, then in order to keep more than 1 state-streams alive, I imagine I would have to merge those streams into one, and use that merged stream as the source$. Correct?

Yes, exactly. The auto-subscribing feature of Subscribe was added in the 0.8.0 release. Before that, you would have to merge all of your streams and pass them manually to the source$.

After 0.8.0 source$ became optional, and it works great for the vast majority of cases. However, there are still some cases where you still need to manage your subscriptions manually... Either because you want to activate them regardless if a component is mounted or not, or to avoid the double-render that Subscribe does when mounting for the first time (and maybe other cases I haven't found yet).

[jyssh]

Yes, the merged stream would involve some maintenance.

and maybe other cases I haven't found yet

I think my usecase would qualify too - maintain a stream of an input value. I would have to pass a default value of empty string "" to `bind`. Otherwise, `<Subscribe>` would just stick to using the fallback component; there would be no value passing into the stream without the input component loading. So in this case, I guess passing default value to bind is necessary. So I would have to use a merged `source$`. If there is another way, then I would appreciate any pointers.

…

On Thu, 7 Sep 2023, at 19:38, Victor Oliva wrote: > If <Subscribe source$> is the only way, then in order to keep more than 1 state-streams alive, I imagine I would have to merge those streams into one, and use that merged stream as the source$. Correct? > Yes, exactly. The auto-subscribing feature of `Subscribe` was added in the `0.8.0` release. Before that, you would have to merge all of your streams and pass them manually to the `source$`. After 0.8.0 `source$` became optional, and it works great for the vast majority of cases. However, there are still some cases where you still need to manage your subscriptions manually... Either because you want to activate them regardless if a component is mounted or not, or to avoid the double-render that `Subscribe` does when mounting for the first time (and maybe other cases I haven't found yet). — Reply to this email directly, view it on GitHub <#308 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOTU46PXNHAZXM2KE4NIPLXZHIMVANCNFSM6AAAAAA4OMBB4Q>. You are receiving this because you authored the thread.Message ID: ***@***.***>