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

STUD-300: Implement 404 "Page Not Found" error page for NEWM Studio #848

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

dmkirshon
Copy link
Contributor

Add:

  • Page Not Found component
  • Asset for Page Not Found Component

Update:

  • Route navigation when attempting to hit a page that doesn't exist

Note:

  • Maintained navigation logic for songs and collaboration artist pages, so that if an incorrect ID is used it will fail and return to the appropriate route path.

@dmkirshon dmkirshon requested a review from a team as a code owner January 28, 2025 17:41
@dmkirshon dmkirshon self-assigned this Jan 28, 2025
@dmkirshon dmkirshon changed the title STUD-300: Implement 404 'Page Note Found" error page for NEWM Studio STUD-300: Implement 404 'Page Not Found" error page for NEWM Studio Jan 29, 2025
@dmkirshon dmkirshon changed the title STUD-300: Implement 404 'Page Not Found" error page for NEWM Studio STUD-300: Implement 404 "Page Not Found" error page for NEWM Studio Jan 29, 2025
Copy link
Contributor

@scandycuz scandycuz left a comment

Choose a reason for hiding this comment

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

Looking good but had some comments.

"/home/upload-song",
"/home/upload-song/advanced-details",
"/home/upload-song/confirm",
];
Copy link
Contributor

@scandycuz scandycuz Jan 29, 2025

Choose a reason for hiding this comment

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

This approach could create some issues, as we'll need to make sure to always update this array when adding a new route, or it could result in the 404 component being incorrectly displayed. Instead, it would be better to declare the routes variable externally and then derive this array from them. E.g.

const routes = [{
  path: "advanced-details",
  ...
}]

const validRoutes = routes.map((route) =>  `/home/upload-song/${route.path}`)

...

if (!isValidPath) {
  return <PageNotFound redirectUrl="/home/upload-song" />;
}

return (
  <WizardForm
    routes={routes}
    ...

That way it only has to be updated in one place, when the routes are declared.

Copy link
Contributor

Choose a reason for hiding this comment

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

The 404 redirect functionality could also be included in the WizardForm component, although I feel less strongly about that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense to consolidate the routes, will make those changes.

I was trying to keep to the highest level where the routing logic was made. WizardForm is used in multiple different contexts so it felt off to integrate any triggering there.

Copy link
Contributor

@scandycuz scandycuz Jan 30, 2025

Choose a reason for hiding this comment

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

Yeah, I don't have a strong opinion on having the logic in the WizardForm. There are pros and cons to doing it that way.


if (!isValidPath) {
return <PageNotFound />;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this useEffect? Couldn't we just use

if (!isValidPath) {
  return <PageNotFound />;
}

directly? It would make the code a bit cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean to remove the useEffect and convert the valid path conditional into a function? I will play around with removing the useEffect and see how the rendering is affected by it.

Copy link
Contributor

Choose a reason for hiding this comment

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

I supposed a benefit of having it in a useEffect call is that it would only run once. It could be fine to keep it there, on second thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants