Original subtitles

Let's simulate an error.

And for that, we can, for example, remove .json,

something Firebase doesn't like.

And if we do it, and I reload,

we therefore fail to load the data.

And we don't see anything here in our app,

but we see it if I open the developer tools.

There we see that we have an error.

We failed to fetch the data.

And of course our typical users

will not check their console.

Therefore, we wanna show the error also here on this screen.

And it's up to you how you wanna show it.

I at least wanna show an error message down here

instead of loading.

Hence, we need a third state.

We need a state that determines

whether we have an error or not.

So an httpError, for example,

but the state name is up to you.

So here we have that.

And initially the value here is false or maybe null

or simply undefined.

Because it's not just a true-false value,

later, instead, I wanna have the error message here.

And initially I don't wanna have any value.

So an undefined value.

So not passing any default value like this should be fine.

We could also set it to null to be more explicit

about our goal of not having any value initially,

but I'll go with undefined.

Now when we fetch data and we fail,

I wanna, well, set my error.

And for this, we, first of all need to find out

if we failed.

Now, for this, I wanna check if response okay is falsey,

so if it's not okay, hence the exclamation mark.

And we'll make it into this if check

if we have some errors status code reported back

by the server.

And if that should be the case,

I wanna throw a new error here where I say something

went wrong.

And we could also look into the error response

and see if the server gave us a more useful error string.

But here I'll just stick to this generic error message.

And then throwing it as a new error,

which means that the lines thereafter won't execute.

Instead, now we wanna handle this error.

And that's another advantage

of using a separate function for wrapping this fetch logic.

This fetchMeals function will now throw an error

if something goes wrong with sending that request.

Therefore, we can go to the place where we call fetchMeals,

which is still inside of user fact,

but outside of the fetchMeals' function, of course.

And we can simply wrap this with try-catch.

So we can try and catch here.

So we try calling fetchMeals.

But if inside of that function an error is thrown,

as is the case here,

then we make it into this catch block,

which is still inside the effect function

but outside of the fetchMeals function.

And then here we can do whatever we wanna do.

I wanna setIsLoading to false

because we're not loading anymore.

Even if it's an error, we're done loading.

And then wanna set error, setHttpError,

cue the error caught.

So we do get access to that error here when using try-catch,

and therefore I can set the httpError

to the error we're getting.

Or to be precise, to the error message.

We'll get an error object here.

And that object by default has a message property.

When we generate an error like this,

and we pass a string to the constructor,

that string will be stored

in the message property of the created error object.

And with that, we should be setting this error state.

Now we can also utilize that and we can check.

Maybe after we checked for whether we're loading,

we can check if httpError is truthy,

so if it has a string with some text inside of it,

for example.

I mean, in that case, return yet another state.

In that case, I wanna return a section

with a text of httpError, so where I output my error text.

And I'll give this a class of meals error,

which we have yet to add,

and we can quickly add this together.

MealsError here.

Here, I'll also set this to text-align center

but set the color to red.

And that will not be too beautiful.

I just wanna have this little bit more errors-ish style.

You can, of course, fine tune the styling

exactly as you want it.

So now with that, if we save this and I reload here,

we'll notice something interesting.

It's still only says loading here.

Now that can be tricky to spot.

The reason for that is that we're using try-catch,

but keep in mind that fetchMeals is an async function,

and therefore, it always returns a promise.

Now, if we throw an error instead of a promise,

that error will cause that promise to reject.

So we can't use try-catch to wrap it

unless we also await this for which we would need to turn

our Effect function here into an async function,

which we're not allowed to do.

Now, we could still work around that

by putting that into a separate function,

which we call thereafter

so that we have separate functions,

one for sending the HTTP request

and one for error handling.

And that be absolutely fine.

But here, I think it's a bit easier to simply use the fact

that it's a promise and add to catch method on it.

Since that returns a promise,

you can add then to handle success cases

when the promise fulfills successfully.

And we can add catch to handle errors

coming up inside of the promise.

And therefore, instead of try-catch here,

we wanna catch the error we're getting

and move that code here into this catch block.

And that's the traditional promise only way

of handling an error inside of a promise.

And I hope I could make it clear why we need this here.

With that, if we saved this, if I reload,

we see loading briefly and then failed to fetch.

And again, of course, we can definitely improve

the error handling here.

we can show a more to useful error message

but here my focus is to show you how it generally works.

Because what you now render on the screen,

that's of course not related to HTTP requests

or anything like that.

Here, you can now build any user interface you want.

But that therefore is how we could also handle errors.

And with that, I'll read .json here

to get rid of that error.

And once we do that and we reload,

we of course do load the data successfully again.

And therefore, with that, we now implemented

this third feature you're fetching, meals data.

Now, let's work on a checkout and order form

so that we can fetch some user data,

which we then, as a last step,

also submit to the server as an order.