docusaurus: Infinite network requests/refresh loop while accessing docs

šŸ› Bug Report

Infinite refresh & network request loops are made while accessing any other page except the homepage.

This issue does not occurs when a doc page is navigated from homepage. This issue only occurs when the website is deployed. Not when the build is locally served and tested.

Prerequisites

  • I’m using the latest version of Docusaurus.
  • I have tried the npm run clear or yarn clear command.
  • I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
  • I have tried creating a repro with https://new.docusaurus.io
  • I have read the console error message carefully (if applicable)

Description

Have you read the Contributing Guidelines on issues?

Yes

Steps to reproduce

  1. Visit website deployed using https://60d4d94678faef62fcfa902f--zowe-docs-testing.netlify.app/stable/user-guide/install-zos (Page falls in an infinite refresh loop)

OR

  1. Visit https://60d4d94678faef62fcfa902f--zowe-docs-testing.netlify.app/
  2. Navigate to any other section from navbar and refresh the page.

Steps to build the website locally

  • Clone the specific branch: git clone --branch zowe-docs-v2 https://github.com/zowe/docs-site.git
  • Install dependencies: npm install
  • Build locally: npm run build and deploy at a URL

Expected behavior

The doc page is expected to load up normally.

Actual behavior

The doc page does not loads up.

Your environment

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 18 (7 by maintainers)

Most upvoted comments

It’s not clear what you mean. Which static file type, and which optimization?

In the static folder, we are directly serving various HTML, CSS & JS files in every version which are being rendered like this. As mentioned in the Docusaurus Documentation, these files in the static folder are not post-processed or minified.

I was asking if we can further optimize these files and save some more time.

Look at what we do on the Docusaurus site itself: not all versions are on the site, and older versions can remain accessible by using archived standalone deployments, external link added to the end of the dropdown:

Yes, we have been planning to archive old doc versions and seperate it as done on the Docusaurus website. It might significantly improve build time!

Note, as you are using Netlify, to leverage Webpack 5 caching (much faster rebuild times), you can use the Netlify cache plugin, as we do on the Docussaurus site.

Thanks I will take a look!

Note, as you are using Netlify, to leverage Webpack 5 caching (much faster rebuild times), you can use the Netlify cache plugin, as we do on the Docussaurus site:

https://github.com/facebook/docusaurus/blob/master/website/netlify.toml#L22

Update: Checked with trailingSlash undefined & using fromExtensions: ["html"] based on the latest canary release works fine. Page redirect works!

But with trailingSlash: false & not using fronExtensions: ["html"] gives ā€œPage Not Foundā€. Check here: https://60db93eee46b29138797921e--zowe-docs-testing.netlify.app/stable/getting-started/overview.html

If any link is /x/y.html/ (with a trailing slash), then it redirects on /x/y. But gives ā€œPage Not Foundā€ on /x/y.html links

@covalentbond on beta.2 we have some breaking changes regarding the version banner you talk about. The DocVersionBanner has been renamed in https://github.com/facebook/docusaurus/pull/5052 You must update your swizzled DocItem code (see https://github.com/slorber/zowe-test/commit/1e2263f793b394241d2b2f686a2141561f239288), this will fix the issue you have. In general it’s worth checking breaking changes on swizzled components when such UI bugs happen.

Unexpectedly, your site still builds fine despite this breaking change. This is because I publish docusaurus official releases from my local computer and didn’t run any cleanup before the publish, so the dist folder still contains the old component (will fix that).

Not upgrading this code for beta.3 and canary releases would give you an error such as:

Module not found: Error: Can’t resolve ā€˜@theme/DocVersionSuggestions’ in ā€˜/Users/sebastienlorber/Desktop/docs-site-zowe-docs-v2/src/theme/DocItem’


Now let’s go back to our redirect problem.

Here’s what has changed:

beta.0

  • Real file: build/v1.21.x/getting-started/overview/index.html
  • Redirect file: build/v1.21.x/getting-started/overview.html/index.html
  • Redirect file: build/v1-21-x/getting-started/overview/index.html

beta.2

  • Real file: build/v1.21.x/getting-started/overview/index.html
  • Redirect file: build/v1.21.x/getting-started/overview.html āŒ
  • Redirect file: build/v1-21-x/getting-started/overview/index.html

The overview.html/index.html filename became overview.html.

I’m thinking about reverting this behavior change of the redirect plugin for better retro-compatibility.


However, some important things to consider:

  • Netlify already redirects your /x/y.html to /x/y, why do you need the fromExtensions: ["html"]? (this is the source of problem)

  • We now recommend using trailingSlash: true/false instead of undefined, particularly for Netlify, as it adds by default a trailing slash to URLs with a server redirect, which impacts SEO/perf/UX. See this URL: https://zowe-docs-testing.netlify.app/stable/getting-started/overview => Netlify adds a / at the end

In general, I created https://github.com/slorber/trailing-slash-guide to hep you figure out these problems by exposing the differences between different static hosts

You should be able to fix this problem today by using one of those 2 potential solutions, but I’d recommend both of them.