re-rxjs / react-rxjs

React bindings for RxJS
https://react-rxjs.org
MIT License
550 stars 19 forks source link

Uncaught Error: Missing Subscribe #270

Closed mbret closed 2 years ago

mbret commented 2 years ago

Hello, I am getting this error whenever I use bind() without the second parameter (default value).

Even a simple

const [useFoo] = bind(of(1))

const Foo = () => {
  useFoo()
}

triggers the error.

const [useFoo] = bind(of(1), any)

this works however

danizord commented 2 years ago

@mbret you have to either use <Subscribe> or pass a default value: https://react-rxjs.org/docs/core-concepts#streams-as-state

voliva commented 2 years ago

A summary of that docs section that's most relevant to the question is:

Given

const [useFoo, foo$] = bind(of(1))

When you don't have defined a default value, what should useFoo() return the first time it's run, if no one has subscribed to the shared observable (foo$) yet?

It just can't return anything. useFoo() would have to subscribe to the observable, which would violate React's rules about subscribing on render. And even if it did, there's no guarantee that the observable emits something synchronously so that it can be returned on that hook call. In this specific case it would, because it's of(1), but on most of the cases it actually won't.

So if you haven't defined a default value for that hook you need an active subscription to the underlying observable beforehand. <Subscribe> can help in two ways:

  1. It takes in a source$ property, which you can use so that it subscribes to that observable before rendering its children. (less "magic" than the other way)
  2. It takes in all the subscriptions needed by its children automatically - More powerful, but with great power comes great responsibility.

What's actually happening when useFoo() is called for the first time is (and why the error "Missing subscribe" is thrown):

(I need to make a flow chart out of this 😅 )

The parent <Subscribe> is a component that has already been mounted, so it can handle all the subscriptions of its children even when they are getting rendered for the first time. The only thing to note is that the owner of that subscription is the <Subscribe>, not the actual child. If the child that triggered one specific subscription unmounts, the subscription will still be active. The component that will clean up that subscription is that specific <Subscribe>, its owner, once it unmounts.

That's why the second approach is powerful, reduces a lot of boilerplate, but you need to be careful - Using a <Subscribe> on the root of your application is probably a bad idea, since it will pick up every subscription of every child and keep them alive throughout the whole lifetime of your app.

We still need to add docs for this, but on a recent version we released <RemoveSubscribe> (source code), in order to prevent some children from accessing a parent <Subscribe> directly, which can be useful to work around that.