-
Notifications
You must be signed in to change notification settings - Fork 156
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
Remove internal suspense boundary #298
Comments
Would it be useful to provide a fallback property to the props? |
Not really for my use-case tbh, because it doesn't enable composability in the same way. E.g. imagine this scenario <Canvas>
<Suspense fallback={<Loading />}>
<ComponentThatLoadsAsset />
<Physics>
<ComponentThatLoadsAsset />
</Physics>
</Suspense>
</Canvas> |
i agree, it would be more flexible if it's in userland. it is a breaking change though, would require a new major. btw @alexandernanberg your example wouldn't work, you can't have raw text or dom nodes within the canvas, but this would be ok: <Suspense fallback="Loading...">
<Canvas>
<ComponentThatLoadsAsset />
<Physics>
<ComponentThatLoadsAsset />
</Physics>
</Canvas>
</Suspense> |
@drcmda Oh right, good point, was just quickly typing out pseudo-code 😄 |
I can't see a good reason why there is a suspense boundary inside the library, this should ideally be handled by consumers for more granular control. E.g. consumer might not want to render
null
.use-cannon/src/index.tsx
Lines 8 to 14 in 543f3e2
This would unfortunately be a breaking change, but in the long run I think it's a good one.
The text was updated successfully, but these errors were encountered: