Improve the speed of displaying instant feedback during navigation

[mpabarca]

Description

• Introduce loading UI state of Nextjs to the group route (home).
• Rearrange routing structure on route group (home) in order to use the proper loading UI state.
• Add launch.json to easy debug the website on development.
• Add nextjs-toploader to show instant feedback while navigating through the website to cover certain slow responses from NextJS.

Motivation and Context

Until now, the project has used different approaches to display a loading UI state when a user interacts with the site, such as navigating between pages, clicking buttons that perform specific actions, or fetching data for the Documentation Viewers (Swagger UI, Redocly, and Stoplight).

This PR introduces a built-in Next.js loading UI state to enhance navigation through the pages, specifically for the group route (home), which includes the /welcome, /new, and /[...slug] pages.

As we continue to experiment with achieving a fluid UI that provides instant feedback, smooth transitions, and consistent data, the following section will explain the rationale behind certain decisions.

⚠️ The next part is only for documentation purposes ⬇

Instant feedback when the user navigates through SSR pages for the first time

Note 1: The Loading state is an instant loading UI, based on Next.js documentation. It acts as a fallback to display while waiting for the full render of the page (found as loading.tsx).

Note 2: The delay in showing instant feedback for SSR pages (like the /new page) only occurs the first time the user navigates to that page. After that, previously fetched data from earlier renderings will be displayed immediately.

According to Next.js documentation, the loading state during navigation should appear immediately, so this delay shouldn’t be happening. This is where the concept of prefetching comes in. Prefetching essentially preloads the nearest parent loading.tsx to be shown in the group route. However, prefetching is not enabled in development mode.

So to verify that our loading state is working correctly, we need to run the application in production mode locally. You can do this by running npm run build to generate all new SSR files (pages, layouts, loading, etc.), and then npm run start. This will allow you to see prefetching in action, which should speed up the display of the loading state when navigating between pages.

Note 3: If you encounter the issue when running npm run start that says "[UntrustedHost]: Host must be trusted ..." this comes from using NextAuth. You need to update your .env (.local) file and add your host port. You can find more details here.

👀 For more discussion on this specific topic, check out this issue on Vercel

Types of changes

• Bug fix (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)

[simonbs]

I've tested the recent changes and the loading bar integration into the secondary content looks great — nice work!

The loading state in the secondary header is also a cool addition, but I noticed the placeholder content doesn't align perfectly with the loaded state. Check out the video below that compares both states.

Specifically, it looks like we could adjust the following:

• The divider thickness—seems like 1-2px, but we're using 0.5px.
• The header height—appears slightly taller once the content is loaded.
• The right-hand padding—seems a bit too much compared to the loaded content.

@mpabarca Do you think it's possible to have the two states match better? Matching these states more precisely would make the loading effect even more compelling! 🤗

video.mov

[mpabarca]

• The divider thickness—seems like 1-2px, but we're using 0.5px.
• The header height—appears slightly taller once the content is loaded.

@simonbs
You are right! The first two points are done 👌🏼 I didn't realised that you made new changes on the redesign. Thanks for catching those details! 🙌🏼

• The right-hand padding—seems a bit too much compared to the loaded content.

Good point, I didn't thought about a case with no edit section.
What you showed is because there is no "edit" section, so it looks a little bit off.
And because I shouldn't use the code above to show or not show that section.

        {specification.editURL &&
          <Tooltip title={`Edit ${specification.name}`}>
            <IconButton
              href={specification.editURL}
              target="_blank"
              color="secondary"
              edge="end"
            >
              <FontAwesomeIcon
                icon={faPenToSquare}
                size="xs"
                style={{ aspectRatio: 1, padding: 2 }}
              />
            </IconButton>
          </Tooltip>
        }

Now I added a skeleton for the edit section by default. You can take a look how it looks in both cases

Screen.Recording.2024-09-11.at.10.39.49.mov

Screen.Recording.2024-09-11.at.10.40.47.mov

Unless you have a better idea :)

[simonbs]

Now I added a skeleton for the edit section by default. You can take a look how it looks in both cases

That looks great! I think it's totally fine to optimize for the case where we have the edit button.

[simonbs]

🚀✨🚀✨🚀✨🚀✨🚀✨🚀✨🚀

Reverting the approval until we've had a look at Ulrik's comment.

[simonbs]

🚀🔥👏🚀🔥👏🚀🔥👏