-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subscribe incorrectly rendering fallback on initial mount #300
Comments
Of course! Just keep a subscription always open, and then it will always have the latest value in memory. I.e: subscribe to the observable, right after defining it. |
As mentioned in the docs:
The way it does this is by first rendering nothing (or the fallback) on initial render, subscribing to the sources, and then rendering the children passed to it. Not sure if it needs more clarification on the docs, or maybe an explanation on the actual implications of this. If you want to avoid this double-render you'll have to manage the subscriptions further up: Don't use |
I think I understand the points you both are making. My point is that an observable with To @voliva's point, I'll try to raise my Subscribe up my react tree, but I think this isn't quite the behavior I want. If I do that, then the subscription's lifetime is no longer tied to where the data is needed in the react tree. Also--if I understand correctly--if there's an error, I'd need to remount that entire tree to start the subscription again. |
Not necessarily, no. Just because an Observable has been enhanced with
However, the first value can come at any point in time, if it ever comes. So, yeah: just because an Observable has been created through the
Even if that was true (which it isn't), the only way to access that value is through a subscription, and since subscribing to an Observable it's a side-effect, it's something that can't be done on the render phase of the component. It can only be done after the component was mounted. That's b/c due to React concurrent-mode: a render function can be called on a component that will never be mounted (and thus never unmounted), and if that happen then we would be creating unnecessary side-effects and stale subscriptions. Therefore, there is no way to actually access the "current" value of a
We've most definitely failed at explaining the goals and the trade off of our library. Not your fault, of course. We should really improve our docs and explain these things better. |
In theory it's posible to do the same behaviour you want, without relying on React's render cycle, but it's more tedious than just using
I've modified your sandbox to better show you what I mean: https://codesandbox.io/s/elegant-feather-fw2vjs?file=/src/App.tsx If you need error handling, this is something you can also add to your custom subscription management. For this, Edit --- I forgot to mention that there's another alternative which sometimes can also work (in your sandbox it does). You can remove the fallback from const content = toggle ? null : (
<Subscribe>
<Suspense fallback="wait...">
<TodoList />
</Suspense>
</Subscribe>
); Subscribe will still do the double render, but in this case it will render nothing on mount, so the user won't see the fallback "Wait..." for that split second. This is just to say most of the time this behaviour is not noticeable, but there are some cases where it does matter. For those ones, it's better to just declare how your subscriptions are managed through another observable. |
Hi there, great library! I'm having an issue with the rendering lifecycle of
Subscribe
. In the core concepts you mention a drawback ofshareReplay
is that it keeps the last value around in memory--that is actually my desired behavior. e.g. if I navigate from page A -> B -> A, I'd like to hydrate A with the old data immediately and refetch new data in the background. I believe this is the model used by many other data fetching libraries (e.g. react query).To work around this, I just piped a
shareReplay
into my observable, butSubscribe
still isn't picking up on that latest value. On initial mount, it still renders the fallback component for a split second. A reproducible example is here.Is there a way I can achieve this? Or is this a bug with
Subscribe
's initial state?The text was updated successfully, but these errors were encountered: