fix: use matchPath to trick reach router to match router

[apaniel]

Fixes page going blank mentionend in: #5

For the plugin to properly work needs the #9 merged as well

By setting a wildcard in the matchpath the routing at component level is disabled, as it will accept any path when setting the path in the gatsby core production app

Also a check for pagePath has been added to fix the exception happening on gatsby develop

[xavivars]

Temporarily, while #9 and #11 get merged I've published a fork of this plug-in with both PRs merged as https://www.npmjs.com/package/@xavivars/gatsby-plugin-static-site

[wardpeet]

@apaniel90vp could you create a reproduction of the issue you're having, so I can add it to the e2e tests

[apaniel]

Sure, basically the page goes blank when going from the initial page to a second one. As the url keeps being the same, and reach router is configured to show different components per page depending on the url, the router's path for the second page will never match.

Also #11 checks that pagePath exists, as there is a check to validate that is development that seems that is not working anymore 'if (!loader) {
return;
}
'

[wardpeet]

I'm creating a new PR to check for development mode in gatsby. Sadly, I still don't follow 100% what the blank page is all about. Could you create a reproduction or show me some urls. My e2e-test now loads a non Gatsby page and routes to a gatsby site but I might not understand your use case.

[apaniel]

I won't be near a computer until tomorrow, but I can tell you how to see what the blank page is.
@xavivars has a fork repo of the ' `Gatsby Default Starter', where gatsby have been changed to in order to simulate the site flow for different MFEs:
https://github.com/xavivars/gatsbybug

By updating to the latest Gatsby version and to the latest static plugin version on that fork, when going from page 1 to page 2 you will see that the page shows nothing, and that is what #11 is fixing.

[xavivars]

The bug here only reproduces when you're serving the Gatsby app behind a las reverse proxy, changing the the public facing urls from the ones Gatsby exposes. Without this PR, reach-router prevents the page from being rendered at all.

If you look at version 0.0.1 of this plug-in, it was working because we're where changing Gatsby's page url to match window.location, so routing was working.. But with the approach after 0.1, where we do not change Gatsby url at all and simply play with the loader, router expects the url to be Gatsby's url

[wardpeet]

what happens when you use pathPrefix and set it to /notworking as well?

[xavivars]

The piece you're probably missing is we do not access the HTML files via published URL, but always acces it to via a reverse proxy..

Imagine a mother server, running in localhost:12345, than when you access /one it proxies to the Gatsby app /page-1,when accessing /two, it is goes to your Gatsby app /page-2, and when accessing /three, it is goes to to example.com/foobar.

Those /one and /two are the ones that become blank, because Gatsby router only expects them to be loaded via /page-1 one /page-2

[apaniel]

Yep, sorry, I forgot the most important part.
To replicate this behavior locally I do a build, and serve the files from a different route with serve npm package

[wardpeet]

When tests are green I'll be merging and I'll do a publish. Thanks a ton!

[wardpeet]

Thanks, @apaniel90vp this is a great fix! I've added a test case for it so we don't regress.

Sorry to keep you waiting but this truly is amazing! 😍

[wardpeet]

Published in v0.2.1

[xavivars]

@wardpeet we LOVE you!