[gatsby-plugin-preload-fonts] handle trailing slashes in onRenderBody

[nibtime]

Description

I used the plugin and observed, that in some HTML files the preload links for the fonts were missing.
Then I saw, that in font-preload-cache.json, some routes contain a trailing slash, but I generate all my pages without a trailing slash. For those routes, the lookup in the asset map fails.

gatsby/packages/gatsby-plugin-preload-fonts/src/gatsby-ssr.js

Line 22 in f585eb0

if (!cache.assets[pathname]) return

This could be replaced with

const assetsOfPath = cache.assets[pathname] ? cache.assets[pathname] : cache.assets[pathname + "/"]
if (!assetsOfPath) {
  return
}
const assets = Object.keys(assetsOfPath)

Steps to reproduce

Generate some pages at paths with no trailing slashes. I am not sure why sometimes paths are written with trailing slashes and sometimes not in font-preload-cache.json. However, if that happens, lookups will fail in onRenderBody.

Expected result

Preload links should be written in all HTML files with a path match , independent of trailing slashes

Actual result

Preload links are not written in HTML files with a non-trailing-slash path, if asset map contains the same path with a trailing slash as a key for the assets

[pvdz]

Thanks for reporting this :) Do you think this is related to #19543?

[nibtime]

Hi @pvdz
I looked into #19543. Could be related, however there it is reported, that the redirect to a trailing slash only happens in production mode, but the gatsby-preload-fonts runs against a development build. It uses a GraphQL query to fetch all routes.

gatsby/packages/gatsby-plugin-preload-fonts/src/prepare/fetch-routes.js

Lines 8 to 14 in 22ead19

	query Routes {
	allSitePage {
	nodes {
	path
	}
	}
	}

I checked the query results in GraphiQL, all routes are returned without a trailing slash as intended.

However, when navigating to the page in the browser, trailing slashes are added for most pages (not for all pages though, which is strange, since the pages are created with the same logic in createPages.). I do create redirects, however they are not targeted by gatsby-preload-fonts, as it iterates over the results of above GraphQL query, which all are fully qualified page paths.

It think the problem is here:

gatsby/packages/gatsby-plugin-preload-fonts/src/prepare/index.js

Lines 57 to 69 in 22ead19

	page.on(`requestfinished`, req => {
	if (req.url().match(/(socket\.io|commons\.js)/)) return
	logger.info(`load`, req.method(), req.url())
	if (req.method() === `GET` && req.resourceType() === `font`) {
	logger.debug(`match`, req.url())
	const { pathname } = new URL(page.url())
	if (!Object.prototype.hasOwnProperty.call(cache.assets, pathname)) {
	cache.assets[pathname] = Object.create(null)
	}

In this callback, the path is obtained from the Puppeteer page object, which has the same URL as navigating to the page with Chrome and thus has a trailing slash. Then the path with the trailing slash is used as the key for the assets.

The pathname that is passed to onRenderBody in gatsby-ssr.js however does not have a trailing slash and that's why the lookup for that pathname fails (it obviously would just work fine if the page was created with a trailing slash).

gatsby/packages/gatsby-plugin-preload-fonts/src/gatsby-ssr.js

Lines 16 to 22 in 399412a

	exports.onRenderBody = (
	{ setHeadComponents, pathname = `/` },
	{ crossOrigin = `anonymous` } = {}
	) => {
	const cache = loadCache()
	if (!cache.assets[pathname]) return

But all the trouble can be avoided by simply make a fallback lookup with a trailing slash. I will send a PR.

[pvdz]

Assigned to @wardpeet since he also self assigned the PR :)