126 add error handling mechanism to the UI

[ChengShi-1]

What this PR does / why we need it:

In some cases, unexpected errors may occur in the application. To manage these effectively, we need a consistent error-handling mechanism in the UI. This not only ensures that error messages are displayed to users on the page but also enables developers to track errors by viewing detailed messages in the console.

Which issue(s) this PR closes:

• Closes Add error handling mechanism to the UI #126

Special notes for your reviewer:

The error page didn't do component test and e2e test.
Component test: we log errors using the hook useRouteError, which must be used within a data router. However, the component test used memory router.
e2e test: we didn't find a way to throw an error in the test environment to trigger the page. Cypress always caught the errors we throw.

Suggestions on how to test this:

Step 1: Run the Development Environment

1. Execute npm i.
2. Navigate with cd packages/design-system && npm run build.
3. Return with cd ../../.
4. Ensure you have a .env file similar to .env.example, with the variable VITE_DATAVERSE_BACKEND_URL=http://localhost:8000.
5. Navigate with cd dev-env.
6. Start the environment using ./run-env.sh unstable.
7. To verify the environment, visit http://localhost:8000/ and check your local Dataverse installation.

Step 2: Test the feature
Since we could only test it manually, please edit some codes in Dataverse-frontend repository.

1. Inside dataverse-frontend/src/sections/homepage/Homepage.tsx or any other children routes, we could add a line throw new Error('This is an error') before returns.
2. check if the error messages are printed in the console
3. check if the error page UI is shown correctly, with the header and footer
4. check if the button, header and footer work well

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

No

Additional documentation:

[coveralls]

coverage: 97.346% (-0.2%) from 97.53%
when pulling 1bc573e on 126-add-error-handling-mechanism-to-the-ui
into ff8ed38 on develop.

[pdurbin]

Just a drive-by comment about brand name. 😄

[g-saracca]

My two cents, min-height should be dynamic based on a prop.
This min-height is fine if we have the presence of the header and footer.
But if the error occurs at the layout level we will have neither header nor footer, causing the container height to not grow to the full height of the viewport, in that case the min-height should be 100vh I believe

[ekraffmiller]

looks good to me!

[g-saracca]

I would avoid running natives javascript dom selectors to find elements by their tag name or even by a class name, these might change and might not even be the only ones you find.

Take a look at this, is from my lazy imports PR, see this tsx file and this scss one.

So then you only need to pass that prop to the ErrorPage on the root layout path object.

  {
    path: '/',
    element: <Layout />,
    errorElement: <ErrorPage fullViewport />,
    children: [
    ...rest

[ChengShi-1]

OK, I'll follow the example. Thank you!

[ekraffmiller]

Sorry if I approved this prematurely, I thought it was ready for QA, but maybe I misread the ticket!

[g-saracca]

Sorry if I approved this prematurely, I thought it was ready for QA, but maybe I misread the ticket!

Don't worry, is just that I left a comment without a formal review I think