I used to be an actor, but programming jobs are easier to come by. I've been doing this now for 11 years. I focus on pixels and experience, especially on iOS and the web.
Thanks for writing this post up last year - I'm really enjoying playing around with the library!
I'm trying to wrap my head around Suspense and the thing I can't figure out right now, though, is why you have the pattern of calling your hook outside of the Suspense barrier and then passing the throwing reader function into the child component inside the barrier. This seems more difficult to reason about than the pattern in reactfire where the hook call itself can throw a promise. Is there something I'm missing here about Suspense or is this just a convention difference?
I used to be an actor, but programming jobs are easier to come by. I've been doing this now for 11 years. I focus on pixels and experience, especially on iOS and the web.
The issue is that you need some way to persist the state that is in flight to some point outside of the Suspense boundary. Because the Suspense-aware API requires throwing a value, it interrupts the execution of the component(s) underneath the nearest Suspense component, meaning that any values in their state (including their hooks' states) are wiped out.
reactfire gets away with its design pattern because it has the context provider higher up in the component tree where it can hang the loads in progress.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for writing this post up last year - I'm really enjoying playing around with the library!
I'm trying to wrap my head around Suspense and the thing I can't figure out right now, though, is why you have the pattern of calling your hook outside of the Suspense barrier and then passing the throwing reader function into the child component inside the barrier. This seems more difficult to reason about than the pattern in
reactfirewhere the hook call itself can throw a promise. Is there something I'm missing here about Suspense or is this just a convention difference?Ok, I think I figured it out.
The issue is that you need some way to persist the state that is in flight to some point outside of the Suspense boundary. Because the Suspense-aware API requires throwing a value, it interrupts the execution of the component(s) underneath the nearest Suspense component, meaning that any values in their state (including their hooks' states) are wiped out.
reactfiregets away with its design pattern because it has the context provider higher up in the component tree where it can hang the loads in progress.