Giter Club home page Giter Club logo

Comments (9)

brophdawg11 avatar brophdawg11 commented on September 27, 2024 1

Good call! Added in #9581

from remix.

brookslybrand avatar brookslybrand commented on September 27, 2024

It looks like there's a note about using useLoaderData inside of Layout

useLoaderData is not permitted to be used in ErrorBoundary components because it is intended for the happy-path route rendering, and its typings have a built-in assumption that the loader ran successfully and returned something. That assumption doesn't hold in an ErrorBoundary because it could have been the loader that threw and triggered the boundary! In order to access loader data in ErrorBoundary's, you can use useRouteLoaderData which accounts for the loader data potentially being undefined.

Because your Layout component is used in both success and error flows, this same restriction holds. If you need to fork logic in your Layout depending on if it was a successful request or not, you can use useRouteLoaderData("root") and useRouteError():

So I don't think this is a bug, but I do get that the error message is a little confusing. I'm not sure if there's anything we can do to improve the error. Probably a question for @brophdawg11

from remix.

frandiox avatar frandiox commented on September 27, 2024

So I don't think this is a bug, but I do get that the error message is a little confusing. I'm not sure if there's anything we can do to improve the error.

The same thing happens with useRouteLoaderData("root"), though, which is mentioned as something valid.

Weirdly enough, the infinite loop disappears if you pass errorElement to Await: <Await resolve={...} errorElement={'something-non-nullish'}>. It might not be forwarding the error properly to the Suspense boundary if errorElement is missing (or it has null or empty string).

from remix.

michenly avatar michenly commented on September 27, 2024

The example had been updated without the use of useLoaderData

from remix.

brophdawg11 avatar brophdawg11 commented on September 27, 2024

The underlying issue here ends up being that Layout was throwing initially due to the invalid promise value being returned - but then when Layout was rendered again using the ErrorBoundary it would throw again. This would result in us trying to render the built-in default Remix error boundary as children of #document since we skip the <html> shell due to the presence of a root Layout. The DOM rejects this and puts React into the infinite loop.

I think the fix in the PR is safe to detect this scenario when the Layout/ErrorBoundary combo re-threw but the guidance should be that Layout/ErrorBoundary should never throw or else it defeats the purpose of using them since they'll be ignored. If useRouteLoaderData is used in Layout during an error render to bypass the can't useLoaderData in an ErrorBoundary limitation, then it should be very defensive to avoid bubbling further.

from remix.

michenly avatar michenly commented on September 27, 2024

Got it! I can definitely make sure Layout/ErrorBoundary should never throw
A great caveat to note and makes a lot of sense once its explain.

Thank you so much for taking the time @brophdawg11 !

Might be worth it to mentioned in this doc along side of A note on useLoaderDatain the Layout Component ?

from remix.

michenly avatar michenly commented on September 27, 2024

Note that #9566 will fix the infinite loop and falling back to the minimal root layout when Layout throw. Re-open till the issue is close officially.

from remix.

github-actions avatar github-actions commented on September 27, 2024

🤖 Hello there,

We just published version 2.10.0-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

from remix.

github-actions avatar github-actions commented on September 27, 2024

🤖 Hello there,

We just published version 2.10.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

from remix.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.