Mole
`useFetch` not reactive after redirection when SSR is disabled and used in a layout
Layouts are complicated. Have you checked if it reproduces in production build? There is special case for dev mode in layout component: https://github.com/nuxt/nuxt/blob/08d653433dce6f1090f392fe9ad44a4001cbc7b8/packages/nuxt/src/app/components/nuxt-layout.ts#L155-L163
8 replies
Confusing useFetch behavior
I think you may be confused by SSR. If your project runs in SSR mode (the default for Nuxt), the fetch happens on the server and therefore is not visible in dev tools. However, the data should be available to you nonetheless, as it is transferred to the client within nuxt server render payload.
9 replies
Is there an idiomatic way to disable a module?
Most modules with such functionality feature
enabled
or disabled
option. As you said, this must be implemented by the module itself. It is easy enough, I do not think there is a real need for easier way. Example: https://github.com/harlan-zw/nuxt-schema-org/blob/main/src/module.ts#L94-L977 replies
useAsyncData - opt out of reactive error handling
Lovely! I have answered in the discussion about the name. We are on the same page about UX, handling locally is great. Sadly it is oftentimes harder in practice than we would like. That's why rendering full-page error as easy to reach fallback would be fantastic.
I deeply appreciate the work you put on Nuxt and understand the pains working in new paradigm of Suspense and reactiveness everywhere. ❤️
22 replies
Reached heap limit Allocation failed - JavaScript heap out of memory
I stumbled upon very similar error today when coding minimal reproduction. My code was triggering
$fetch('/bad/url')
on /
(could also be done in plugin). Since I did not have special 404 handler, it attempted to fetch home page, which in turn fetched /bad/url
and so on, in a loop. This would ultimately cause stack size to be exceeded.10 replies
useAsyncData - opt out of reactive error handling
^ You would think it works. It does not.
useFetch
is using useAsyncData
internally and thus whatever you throw (eg. using onResponseError
) will be simply caught by useAsyncData
and provided to you as return value.
You could probably wrap useAsyncData
, add the error watcher yourself and throw from it. That's why I explicitly said without wrapping, as this approach forces the developer to write what should be framework code in the userland. In addition to already having custom fetch as per docs link you sent.
Here is example of wrapped useAsyncData
, which mostly works. It does not break out of the scope when called with await
. Which I think may cause other issues.
22 replies
useAsyncData - opt out of reactive error handling
What I am looking for is a way to call
And have it display full page error without having to add anymore local code in the component. No checking
error
value. You can check the error value, I believe proper way to throw full page error would be adding this code below:
My issue with this is, nobody remembers to check error. And in such cases, I would not want the error to be implicitly swallowed (what is error swallowing - wikipedia). It is a very dangerous practice and should always be intentional.22 replies
useAsyncData - opt out of reactive error handling
In this example, you are handling the error locally (
const { error } = useAsyncData(...)
). This is 100% proper way to handle it locally. However, you must have the logic to deal with error
everywhere you call useAsyncData
.22 replies
useAsyncData - opt out of reactive error handling
If you read through the code people post, it almost never handles
error
s. Sure, "minimal reproduction". I am happy to bet on how many of these "minimal reproductions", which coincidently happen to include a ton of unrelated details, omit error handling on purpose. useAsyncData
never throws (ref). People do not understand it. Nuxt team do not understand it (ref, cc @Atinux). Are mere mortals supposed to understand?22 replies
useAsyncData - opt out of reactive error handling
It is reasonable one (eg. kappa bot) would think it works. But it does not. Nothing you do inside useAsyncData bypasses the error boundary (ref: https://stackblitz.com/edit/github-mzystala?file=app.vue). A project likely already has a wrapper for API calls, which translates http response into frontend-local error object. But
useAsyncData
is playing Pokemon, catching 'em all.22 replies