Skip to content

API calls need to have status codes checked in the frontend #168

Closed
campb303 opened this issue Jan 22, 2021 · 4 comments
Closed

API calls need to have status codes checked in the frontend #168

campb303 opened this issue Jan 22, 2021 · 4 comments
Assignees
Labels
bug An issue that results in webqueue2 breaking feature-request Request for functionality that has not already been implemented high-priority Needs immediate extra focus

Comments

@campb303
Copy link
Collaborator

There's currently an issue with the API that causes an HTTP 500 response when getting queue data. These types of responses are not handled in the UI and should be. Instead of an error message appearing, the UI crashes like this:

Screen Shot 2021-01-22 at 2 21 02 PM
@campb303 campb303 added bug An issue that results in webqueue2 breaking feature-request Request for functionality that has not already been implemented frontend labels Jan 22, 2021
@campb303 campb303 added this to the v1-readonly milestone Jan 22, 2021
@campb303 campb303 self-assigned this Jan 22, 2021
@campb303 campb303 modified the milestones: v1-proof-of-concept, v2-production-ready-read-only Feb 5, 2021
@campb303 campb303 removed the frontend label Mar 17, 2021
@campb303 campb303 added the high-priority Needs immediate extra focus label May 17, 2021
@campb303
Copy link
Collaborator Author

Waiting on API changes.

@campb303
Copy link
Collaborator Author

campb303 commented Jul 6, 2021

This can resume. API changes were made to support return codes.

@campb303 campb303 removed this from the production-ready-read-only milestone Jul 6, 2021
@wrigh393
Copy link
Collaborator

Here is a summary of how this feature was implemented.

Getting the API response

In order to handle getting the response status from the API when an error occurs, I made a few changes to the AppView component. First I created two state variables, error and response.

  • error: This variable contains a boolean. It is set to true if the ok prop of the JSON response is false.
  • response: This is an object that stores the response code (ex.404) and the status message that is returned. This is also set when the ok prop of the JSON response is false.

I also added an if-else statement to evaluate when the ok prop of the JSON response is true or false. Here is the code diff to show the changes made

+	const [error, setError] = useState(false)
+	const [response, setResponse] = useState({ status: '', message: '' })


//some code...

- setQueues(queueJson);
- setIsLoading(false)
+ if (apiResponse.ok) {
+     setQueues(queueJson);
+     setIsLoading(false)
+ } 
+ else {
+    setResponse({ status: apiResponse.status, message: apiResponse.statusText })
+     setError(true)
+			}

UI

The UI for this is simple. It is a collection of Typography components that display the status code and the message. I then used a ternary to display the error UI when the error state value is true and the ItemTable when it is false. Below is the code and a screenshot of how the UI looks.
Code

{error ? 
<Box classes={{ root: classes.errorContainer }}>
    <Typography variant="h1">
        {response.status}
    </Typography>
    <Typography variant="h3">
        Something went wrong.
    </Typography>
    <Typography variant="h5">
        {response.message}
    </Typography>
</Box>
 : 
<ItemTable data={items} rowCanBeSelected={sidebarOpen} loading={isLoading} />
}

Sceenshot
image

Finally, in order to implement this UI, the API now has the ability to request error codes for future error testing or handling.

@wrigh393
Copy link
Collaborator

This issue was addressed with #220. Closing.

Sign in to join this conversation on GitHub.
Labels
bug An issue that results in webqueue2 breaking feature-request Request for functionality that has not already been implemented high-priority Needs immediate extra focus
Projects
None yet
Development

No branches or pull requests

2 participants