-
Notifications
You must be signed in to change notification settings - Fork 21
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
Error code #53
Comments
Interesting idea, but I'll try to convince you that this should be left as it is. Having One of the nice things about having It means the scope of On the But for anything more advanced, like dealing with error codes, collecting multiple errors in an array, etc, the idea is that you do this in the function in |
For example, suppose that we had the error object, then you could do this:
But the idea is that, instead, you should just move that error handling code inside the
|
I generally agree, but we have a lot of use of frontload, around 450 of them in our app. My idea was to catch all the errors and return an array of errors and let the components decide what to do with them. |
Ah, sure. Having thought about this, I think adding the error object to Reviewing the two examples above, actually the first way is a lot simpler in many ways, especially if you are just doing things like checking codes. What I wanted to avoid was expanding the scope to do any 'error handling' type stuff, but actually just returning the error object is basically just the same as returning a boolean but more flexible and useful! I'd propose adding an additional |
So first of all, sorry for the slow turnaround on this. It's been a very busy January! I've been thinking about the solution proposed in your PR . Reviewing this actually made me realise the reason I'd made the The problem with returning the error object as is is serialization - rehydrating it on the client after the server render. An error thrown on the server would have to be serialized in some way so that all the info you use from it to render things in your components can also be passed to the client. I think a fairly elegant solution to this is the same pattern used by many web frameworks - the ability to configure a global error handler for frontload that can do this job. That is, you set it once, and then any frontload that runs and throws an Error, on server or client, would run through this error handler automatically. So you don't have to write handler code in each one of your frontloads, and you can serialize whatever info you need from each type of error and return it in (probably) the What do you think? |
Hi,
|
Hi,
I think that the
frontloadMeta
should return some data about the error and not onlyerror: true
when we do SSR there is a big difrance between HTTP 500 or HTTP 404, especially when talking about google crawl budget.
I tried to find some data about the error and all i front is the error flag.
maybe return an array of
errors
where it will hold all the errors in theuseFrontload
?The text was updated successfully, but these errors were encountered: