From a19df81c095d7cc190f4b69afa4bab78ffbbf002 Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 11:33:55 -0600 Subject: [PATCH 1/7] Add error handling lesson --- module3/lessons/error-handling.md | 72 +++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 module3/lessons/error-handling.md diff --git a/module3/lessons/error-handling.md b/module3/lessons/error-handling.md new file mode 100644 index 00000000..a131b1ee --- /dev/null +++ b/module3/lessons/error-handling.md @@ -0,0 +1,72 @@ +--- +title: Frontend Error Handling +tags: javascript, fetch, error, catch +module: 2 +--- + +## Introduction + +As front end developers, we should always be concerned about giving our users the best experience possible AND we want to protect our data as much as possible. We never want to store data that is incorrect or inconsistent. We also want our users to be informed about what is going on in the application. Today's lesson will focus on the responsibility of frontend developers when it comes to error handling. + +## Preventing Errors + +
+### Activity + +There are four codepens in **[this collection](https://codepen.io/collection/ExqLWp)**. Spend a few minutes with each codepen (in order, starting with #1!) and answer the questions below: + +- Try to break it! As a user, are you able to send bad data to the backend? + - Note: Open the codepen console (button is in bottom left corner) to see what data is being sent to the backend when you click "Sign Up". +- Is there anything about the input elements that prevent bad data from being entered? +- Is there anything preventing bad data from being sent to the backend on submit? +- Is the error messaging helpful? +
+ + +### Preventing Errors - Key Points +**Whenever possible, we should prevent users from being able to make mistakes in the first place.** + - We should make it as easy as possible for users to do the right thing. Here are some tips: + - Use input types (like [date](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date) and [number](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number)) to restrict the user's input. + - Use [dropdowns](https://www.w3schools.com/tags/tag_select.asp) or [radio buttons](https://www.w3schools.com/tags/att_input_type_radio.asp) to limit a user's options to a preselected list. + - Give the user examples in the [placeholder](https://www.w3schools.com/tags/att_input_placeholder.asp) text to show them what you're expecting. + - [Disable](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/disabled) the form's submit button until all inputs are filled out. + +**If a user makes a mistake, we should provide easy instructions for how to fix it.** + - Make your message specific - tell them exactly what field is wrong and what they need to do to fix it. + +**We should thoroughly check the data before we store it or send it to the backend.** + - Pretend that the backend has zero error handling and it is going to accept whatever you send it. Do not rely on other people doing the error handling - we should be checking our data several times before it gets stored. + - Simply checking that there is *something* there isn't enough. We need to check that the data is accurate and the correct data type (remember that input values always come back as strings!). + +**Whether things go right or wrong, we should give the user feedback.** + - Users should know that the action was successfully fulfilled. + - Users should know if something went wrong (whether it was user error or not). + - We should wait until after the Promise has successfully resolved from a fetch to confirm the outcome with the user. This is what we will talk about next! + + +## Handling Fetch Errors + + + + +
+### Activity + + +
+ +### Handling Fetch Errors - Key Points + +**We should add error handling to the `catch`.** + - The `catch` will fire if the server is completely down. Users need to know that their action was not completed in this scenario. + +**The `.catch` will NOT fire for all fetch errors. We ALSO need to check the `response.ok` property.** + - If we only handle errors that are triggered in the `catch`, we will miss scenarios like `422`s or `404`s where the `catch` does not fire. + +**(Again) Whether things go right or wrong, we should give the user feedback.** + - Users should know that the action was successfully fulfilled. + - Users should know if something went wrong (whether it was user error or not). + - We should wait until after the Promise has successfully resolved from a fetch to confirm the outcome with the user. + - The messaging should be user-appropriate. (Do they need to know it's a 500 error or do they just need to know something went wrong and they should try again later?) From ec3c16cc30169078332cd93d65031016d34594ea Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 11:34:28 -0600 Subject: [PATCH 2/7] Add error handling lesson --- module3/lessons/{error-handling.md => fe_error_handling.md} | 0 module3/lessons/index.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename module3/lessons/{error-handling.md => fe_error_handling.md} (100%) diff --git a/module3/lessons/error-handling.md b/module3/lessons/fe_error_handling.md similarity index 100% rename from module3/lessons/error-handling.md rename to module3/lessons/fe_error_handling.md diff --git a/module3/lessons/index.md b/module3/lessons/index.md index b60c67be..a604cf44 100644 --- a/module3/lessons/index.md +++ b/module3/lessons/index.md @@ -23,7 +23,7 @@ title: Module 3 - Lessons * [Intro To Accessibility](./intro-to-a11y) * [Network Requests - Fetch](./network_requests) - +* [FE Error Handling](.fe_error_handling) * [Responsive Layouts](./css_responsive_layouts) From 6a328d095dfd70c823b2ab62b822884b84efc46f Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 11:35:38 -0600 Subject: [PATCH 3/7] Update lesson list --- module3/lessons/index.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/module3/lessons/index.md b/module3/lessons/index.md index a604cf44..6435932c 100644 --- a/module3/lessons/index.md +++ b/module3/lessons/index.md @@ -15,18 +15,15 @@ title: Module 3 - Lessons * [Intro to React](./react_intro) * [Ideabox Review](./react_ideabox_review) * [Advanced Data Management](./react_advanced_data_management) -* [Intro to Cypress Testing (Prework)](./intro_to_cypress_prework) -* [Intro to Cypress Testing (Lesson)](./intro_to_cypress_testing) * [React Router](./react-router) ## Advanced Frontend Concepts -* [Intro To Accessibility](./intro-to-a11y) * [Network Requests - Fetch](./network_requests) - +* [Intro to Cypress Testing (Prework)](./intro_to_cypress_prework) +* [Intro to Cypress Testing (Lesson)](./intro_to_cypress_testing) +* [Intro To Accessibility](./intro-to-a11y) * [FE Error Handling](.fe_error_handling) * [Responsive Layouts](./css_responsive_layouts) - - ## Fullstack Web Development * [Intro to Service-Oriented Architecture](./intro_to_soa) From 2708d59e679d45d6e99b75e04c12ff383a3faa9d Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 12:26:11 -0600 Subject: [PATCH 4/7] Add error handling lesson --- module3/lessons/fe_error_handling.md | 92 ++++++++++++++++++++++++++-- module3/lessons/index.md | 2 +- 2 files changed, 89 insertions(+), 5 deletions(-) diff --git a/module3/lessons/fe_error_handling.md b/module3/lessons/fe_error_handling.md index a131b1ee..df5269cb 100644 --- a/module3/lessons/fe_error_handling.md +++ b/module3/lessons/fe_error_handling.md @@ -23,7 +23,7 @@ There are four codepens in **[this collection](https://codepen.io/collection/Exq -### Preventing Errors - Key Points +## Preventing Errors - Key Points **Whenever possible, we should prevent users from being able to make mistakes in the first place.** - We should make it as easy as possible for users to do the right thing. Here are some tips: - Use input types (like [date](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date) and [number](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number)) to restrict the user's input. @@ -49,15 +49,99 @@ There are four codepens in **[this collection](https://codepen.io/collection/Exq - +### Set Up +We're going to use the same Ideabox FE and BE that we've used several times in previous lessons. + +1. Re-open **[this react-ideabox FE](https://github.com/turingschool-examples/react-ideabox)** repo. + a. Navigate to that directory + b. Run `git fetch` + c. Run `git checkout error-handling` + d. Run `npm start` +2. You'll also need the **[ideabox-api BE Repo](https://github.com/turingschool-examples/ideabox-api)** up and running. + a. Navigate to that directory + b. Run `node server.js` +3. Make a tab in Chrome for: + a. `localhost:3000`: You should see the React app up and running here + b. `http://localhost:3001/api/v1/ideas`: You should see your list of ideas here
-### Activity +### Explore +1. First, turn off the server. You should see a user-friendly error message in your Ideabox. Explore the React code and find the code that is responsible for making this happen. +2. Now, turn the server back on. The error message should disappear and the cards should correctly populate. Now, try to submit an idea with a missing field (leave either the title or description blank). Pay attention to the following: + - What does the user see? + - Look at the console. Is there an error there? What is the status code? + - Go to `http://localhost:3001/api/v1/ideas`. Was that data POSTed? +Discuss: Do you think the `.catch()` was fired in the second scenario? What is your evidence? Why do you think this is happening?
-### Handling Fetch Errors - Key Points +### Triggering the catch + +Hmm...it seems like not all errors trigger the `catch`. Which means we can't rely on the `catch` to let the user know if things have gone wrong. Let's dig into the response object. Let's add a console.log: + +```js + .then(response => { + console.log(response) + return response.json() + }) +``` + +Now, let's compare that response object in two scenarios: + +1. The user fills everything out correctly: +```js +{ + type: 'cors', + url: 'http://localhost:3001/api/v1/ideas', + redirected: false, + status: 201, + ok: true,  +} +``` + +2. The user misses a field: +```js +{ + type: 'cors', + url: 'http://localhost:3001/api/v1/ideas', + redirected: false, + status: 422, + ok: false,  +} +``` + +Do we think we could use any of these properties to check if the network request was successful? + +
+### Possible Solution + +```js + function addIdea(newIdea) { + fetch('http://localhost:3001/api/v1/ideas', { + method: 'POST', + headers: { + 'Content-Type': 'application/json', + }, + body: JSON.stringify(newIdea), + }) + .then(response => { + if (!response.ok) { + throw new Error(response.status); + } + return response.json() + }) + .then(data => setIdeas([...ideas, data])) + .catch(error => { + console.log(error) + setError('Oops! Something went wrong! Please try again in a couple minutes.') + }) +``` +
+ +By using the line `throw New Error()`, we are able to manually trigger the `catch`. Now, that error handling in our `catch` is firing for a 422 error! Yay! + +## Handling Fetch Errors - Key Points **We should add error handling to the `catch`.** - The `catch` will fire if the server is completely down. Users need to know that their action was not completed in this scenario. diff --git a/module3/lessons/index.md b/module3/lessons/index.md index 6435932c..9ec5ebaa 100644 --- a/module3/lessons/index.md +++ b/module3/lessons/index.md @@ -22,7 +22,7 @@ title: Module 3 - Lessons * [Intro to Cypress Testing (Prework)](./intro_to_cypress_prework) * [Intro to Cypress Testing (Lesson)](./intro_to_cypress_testing) * [Intro To Accessibility](./intro-to-a11y) -* [FE Error Handling](.fe_error_handling) +* [FE Error Handling](./fe_error_handling) * [Responsive Layouts](./css_responsive_layouts) ## Fullstack Web Development From 5e89a9212d355260b1f9aec8872b29fc92ada428 Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 12:29:06 -0600 Subject: [PATCH 5/7] Add question about preventing errors --- module3/lessons/fe_error_handling.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/module3/lessons/fe_error_handling.md b/module3/lessons/fe_error_handling.md index df5269cb..57af77a4 100644 --- a/module3/lessons/fe_error_handling.md +++ b/module3/lessons/fe_error_handling.md @@ -141,6 +141,12 @@ Do we think we could use any of these properties to check if the network request By using the line `throw New Error()`, we are able to manually trigger the `catch`. Now, that error handling in our `catch` is firing for a 422 error! Yay! +
+### Discuss + +Do you think we should send a POST request to the backend that has missing fields? What could we do to prevent this from happening? +
+ ## Handling Fetch Errors - Key Points **We should add error handling to the `catch`.** From 46f707c24bf1e05fa3f8b519029f1711239467e6 Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Wed, 23 Oct 2024 12:31:38 -0600 Subject: [PATCH 6/7] Remove comment --- module3/lessons/fe_error_handling.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/module3/lessons/fe_error_handling.md b/module3/lessons/fe_error_handling.md index 57af77a4..07717e05 100644 --- a/module3/lessons/fe_error_handling.md +++ b/module3/lessons/fe_error_handling.md @@ -46,9 +46,6 @@ There are four codepens in **[this collection](https://codepen.io/collection/Exq ## Handling Fetch Errors - ### Set Up We're going to use the same Ideabox FE and BE that we've used several times in previous lessons. From e64cc250963a31853ffeee67c628db48b9f014a5 Mon Sep 17 00:00:00 2001 From: Kayla Gordon Date: Mon, 4 Nov 2024 11:46:20 -0700 Subject: [PATCH 7/7] Add research step to error handling --- module3/lessons/fe_error_handling.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/module3/lessons/fe_error_handling.md b/module3/lessons/fe_error_handling.md index 07717e05..16162e9e 100644 --- a/module3/lessons/fe_error_handling.md +++ b/module3/lessons/fe_error_handling.md @@ -110,6 +110,19 @@ Now, let's compare that response object in two scenarios: Do we think we could use any of these properties to check if the network request was successful? +
+### Research + +Let's spend a little time looking through these docs: +- [Response: ok Property](https://developer.mozilla.org/en-US/docs/Web/API/Response/ok) + - Q: What is the `ok` property? + - Q: When will `ok` resolve to `true`? `false`? +- [Throw](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/throw) + - Q: Where does `throw` send you in the code? +- [Error](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error#throwing_a_generic_error) + - Q: What does `throw new Error('some message here')` do? +
+
### Possible Solution