Fix <HomeSelector> race condition

[maximilianoertel]

Proposed changes

This PR fixes a race condition in the <HomeSelector> that would cause the user type check isAdmin to switch back and forth between true and false during page load, effectively causing unwanted renders and side effects on the homepage. This issue seems to only be reproducible after upgrading to the latest @tanstack/vue-query version as done in the base branch.

With the proposed changes, the improved loading of the homepage provides a smoother user experience by preventing the flashing of unwanted components and slightly better performance due the asynchronously import of the homepage components.

Before

before.mov

After

after.mov

Note

The empty-state placeholder is, unfortunately, still flashing in the updated version. This is due to the nature of isLoading initially evaluating to false when a TanStack query is initially disabled. This is currently being addressed and will be fixed separately. Additionally, we should address the navbar loading delay as reported in: yeatmanlab/roar/issues/322

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (non-breaking change that does not add functionality but makes code cleaner or more efficient)
• Documentation Update
• Tests (new or updated tests)
• Style (changes to code styling)
• CI (continuous integration changes)
• Repository Maintenance
• Other (please describe below)

Checklist

• I have read the guidelines for contributing.
• The changes in this PR are as small as they can be. They represent one and only one fix or enhancement.
• Linting checks pass with my changes.
• Any existing unit tests pass with my changes.
• Any existing end-to-end tests pass with my changes.
• I have added tests that prove my fix is effective or that my feature works.
• If this PR fixes an existing issue, I have added a unit or end-to-end test that will detect if this issue reoccurs.
• I have added JSDoc comments as appropriate.
• I have added the necessary documentation to the roar-docs repository.
• I have shared this PR on the roar-pr-reviews channel (if I have access)
• I have linked relevant issues (if any)

Justification of missing checklist items

n/a

Further comments

n/a

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	1.2%	91 / 7573
🔵	Statements	1.19%	96 / 8065
🔵	Functions	0.95%	19 / 1996
🔵	Branches	0.73%	31 / 4235

File Coverage

File	Stmts	% Branch	% Funcs	% Lines	Uncovered Lines
Changed Files
src/composables/useUserType.js	100%	87.5%	100%	100%
src/constants/auth.js	100%	100%	100%	100%
src/pages/HomeSelector.vue	0%	0%	0%	0%	36, 36-37, 37-38, 38, 40-42, 44-45, 47-53, 48-53, 51-52, 55-56, 58, 60-63, 61, 61-62, 65-67, 66, 66, 69-71, 73-75, 77, 79, 79, 81-87, 82-86, 83, 85, 88-90, 93-96, 94-95, 100, 104-107, 106, 110-119, 111-113, 115-118, 116-117, 122-134, 123-126, 124-125, 127, 127-133, 129-132, 131, 136-140, 137-139, 138, 3, 5

Generated in workflow #57

[github-actions]

Visit the preview URL for this PR (updated for commit 7825bba):

https://roar-staging--pr751-fix-homeselector-loa-j3kmclgx.web.app

_{(expires Thu, 29 Aug 2024 17:10:51 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 2631e9c58fd0104ecbfddd72a62245ddac467460}

[cypress]

---

Test summary

26 • 0 • 0 • 0 • 0

---

Run details

Project	roar-dashboard-e2e
Status	Passed
Commit	7825bba
Started	Aug 22, 2024 5:12 PM
Ended	Aug 22, 2024 5:17 PM
Duration	04:47 💡
OS	Linux Ubuntu -
Browser	Edge 127

View run in Cypress Cloud ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Cloud

[ksmontville]

This looks great!

Do you think that it makes sense to have SUPER_ADMIN as a third userType to return? Based on the presence of the super_admin key in the user document.

We do have some additional checks and renders throughout the code base that rely on differentiating between an ADMIN and a SUPER_ADMIN. Would adding that distinction in this PR reduce complexity down the road?

I also noticed the initial "flashing" of the empty state, when administrations are initialized but not yet loaded. Hopefully we can address this, as well.

This also happens when switching from a student account to an admin account, and vice versa. The navbar seems to store the previous state of the user and displays a student username on the admin account, and the admin username on the student account. I suspect this is related to the navbar PR that you are working on.

Just some thoughts, otherwise I approve.

[maximilianoertel]

Thanks for the review @ksmontville!

100% with you on extending the useUserType composable, planing on using it here.

This also happens when switching from a student account to an admin account, and vice versa. The navbar seems to store the previous state of the user and displays a student username on the admin account, and the admin username on the student account. I suspect this is related to the navbar PR that you are working on.

Regarding the above, you could you please confirm: when you mean "switching between student and admin account", you mean you log out, log in again and the name is incorrect in the navbar, correct? If so that is currently expected as I still need to implement query invalidation on the main PR so that should be addressed/fixed shortly