Skip to content
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

Refactor: makes session management a bit more readable #304

Merged
merged 9 commits into from
Aug 23, 2023

Conversation

lanterno
Copy link
Contributor

@lanterno lanterno commented Aug 17, 2023

(Skip first two commits, they have already been merged in another PR - rebase avoided for other reasons).

Changes

  1. Rename the session variables to follow camelCase.
  2. Renames other various variables to provide more readability.
  3. Return 401 when a user in unauthenticated, instead of 400.

for n. 3, I only apply that to one endpoint. In a following PR, I want apply this to all other endpoints, but I need to think of a smarter way to unify the behaviour between all endpoints that require authentication.

PascalinDe
PascalinDe previously approved these changes Aug 17, 2023
Copy link
Contributor

@PascalinDe PascalinDe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great :)

@pierluca pierluca dismissed PascalinDe’s stale review August 22, 2023 12:23

The merge-base changed after approval.

@pierluca
Copy link
Contributor

pierluca commented Aug 22, 2023

Regarding N° 3 and your comment, you might want to look at ExpressJS error handling.
It might be possible to define a set of exceptions and just write a generic error handler based on the exception type: https://expressjs.com/en/guide/error-handling.html

Comment on lines 227 to 229
const response = await fetch(ENDPOINT_PERSONAL_INFO, req);
let result;
try {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beware ! This is a dangerous change.
The fetch API returns a promise.
awaiting on a Promise can throw an exception if the Promise is rejected.
This needs to be in the try/catch block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this to put the try/catch around the whole function. What do you think?

authorization: {},
};
} else {
const txt = await response.text();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the response did not return a 200, doesn't this always throw ?

Copy link
Contributor Author

@lanterno lanterno Aug 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's neither 200 nor 401

Copy link
Contributor

@pierluca pierluca Aug 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what I meant is: isn't response.text() going to throw before your throw new Error(), when there's no HTTP body ? (i.e. no error information other than the HTTP status sent from the backend)

I'm not sure about how the .text() works in the Fetch API, but according to the documentation and the standard it seems it reads the body. Does it succeed on an empty body ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pierluca It succeeds. I tested it.

My test: I restarted the backend, and refreshed the UI causing the backend to return 504. the frontend then displayed the intended message.

if (res.status !== 200) {
const txt = await res.text();
throw new Error(`unexpected status: ${res.status} - ${txt}`);
if (response.status === 200) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do you feel about a switch statement ? 😁

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it. Looks good 👍

@lanterno lanterno requested a review from pierluca August 22, 2023 13:28
@pierluca
Copy link
Contributor

Sonar seems to have a couple of good points

try {
fetchData();
} catch (e: any) {
setContent(<Failed>{e.toString()}</Failed>);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, be careful. Here you're changing the content of the page, I assume.
You shouldn't do that in an async context without verifying if the component is still loaded or not.
You might want to have a read
https://devtrium.com/posts/async-functions-useeffect

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that is correct, but it already existed like this, so I wouldn't want to change it in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But still I'm gonna take the advice for when I can apply am improvement confidently.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I'm just reviewing some of this code for the first time - so I'm pointing out issues as I see them. That doesn't mean I expect all the fixes in the same PR :)

@lanterno lanterno requested a review from pierluca August 22, 2023 15:28
pierluca
pierluca previously approved these changes Aug 23, 2023
Copy link
Contributor

@pierluca pierluca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still a few issues, but nothing specifically belonging in this PR.
I think we can merge :)

@lanterno lanterno dismissed pierluca’s stale review August 23, 2023 07:32

The merge-base changed after approval.

pierluca
pierluca previously approved these changes Aug 23, 2023
@lanterno lanterno dismissed pierluca’s stale review August 23, 2023 08:56

The merge-base changed after approval.

@lanterno lanterno requested a review from pierluca August 23, 2023 08:57
@lanterno
Copy link
Contributor Author

@pierluca Github dismissed your review for some reason.

@lanterno lanterno force-pushed the refactor/makes-session-management-a-bit-more-readable branch from 2ba4455 to 01c4478 Compare August 23, 2023 14:07
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@pierluca pierluca merged commit 2aa1565 into main Aug 23, 2023
@pierluca pierluca deleted the refactor/makes-session-management-a-bit-more-readable branch August 23, 2023 14:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants