Google Cloud function dynamic hosting error with SW

[jasan-s]

I have a cloud function dynamicHosting that renders some html.

I'm using firebase hosting to rewrite the path to the function like so:

    "rewrites": [
      {
        "source": "/dynamicHosting",
        "function": "dynamicHosting"
      },
      {
        "source": "**",
        "destination": "/200.html"
      }
    ]

If I remove the service worker code, the html from the function dynamicHosting render fine however with the service worker enabled the App's 404 component renders.

I tried the following in sw-precache-config file: navigateFallbackWhitelist: [/^(?!\/__).*/, /^\/dynamicHosting\// ]

But still the same result. Is this a FIrebase hosting issue or SW issue? Or just something I'm missing?

[jeffposnick]

Can you point us to a public URL for your deployed Firebase instance? Trying this out would be the quickest way to give you feedback as to what's going on.

[jasan-s]

@jeffposnick here is a url of the deployed project:

And the path for the dymanic hosting where the cloud function should render is'/dynamicHosting'

or just this dynamic path url

The dynamic hosting works if i go the to dynamic path straight before the service registers

[jeffposnick]

I'm not able to get your service worker to register to begin with when I visit that URL, because it's attempted to precache a URL that returns an HTTP 404 response. A service worker generated by sw-precache will fail to install if there's a non-200 HTTP response for any of the URLs listed in the precache manifest. Can you exclude that entry for /404.html from your precache manifest and redeploy so that I could debug further?

[jasan-s]

@jeffposnick it is working now. I first added this to sw-precache config staticFileGlobsIgnorePatterns: [/\.map$/, /asset-manifest\.json$/, /404\.html$/], but that didn't solve it(I assumed it would), so I just removed 404.html from the build folder and uploaded the build folder to hosting. I have confirmed, SW registers.

[jeffposnick]

You have navigateFallback in your sw-precache configuration set to ./200.html.

If you navigate to https://reactstarterwithcreatereactapp.firebaseapp.com/dynamicHosting then the content of 200.html will be returned. When rendered, that content happens to be a screen with a big "404" error message in it, which I guess is why you thought you were getting back a HTTP 404 response. But you're seeing the HTML from 200.html.

The configuration that you provided at the start of this issue explicitly opted-in /dynamicHosting into your navigateFallbackWhitelist. If you want to opt-out, you can try to use a negative RegExp like [/^(?!\/dynamicHosting).*/].

[jasan-s]

yeah your right the 404 is just my apps internal component when it can't find a matching path. Setting [/^(?!\/dynamicHosting).*/] in the navigateFallbackWhitelist still leads to the Service Worker intercepting the dynamicHosting path thus the Firebase dynamic hosting never takes effect.

I put it up on StackOverflow as well, Ill post the solution here If i find one.

[jasan-s]

@jeffposnick the generated service-worker.js includes the following code:

        if (!shouldRespond && navigateFallback && event.request.mode === "navigate" && isPathWhitelisted(["^(?!\\/__).*", "^(?!\\/dynamicHosting).*"], event.request.url)) {
            url = new URL(navigateFallback, self.location).toString();
            shouldRespond = urlsToCacheKeys.has(url)
        }

Can you see a reason why the service worker is still intercepting the path "/dynamicHosting"

[jasan-s]

after the following change it works:

navigateFallbackWhitelist: [/^(?!\/__).*/+ "|" +/^(?!\/dynamicHosting).*/],

[jeffposnick]

Apologies that this took so much effort for you to configure, @jasan-s, and I'm glad that you have things working.

(The configuration story is much better in the next-generation Workbox libraries, as we support both a blacklist and a whitelist for navigateFallback.)

[jasan-s]

Nice glad to hear that.

[jasan-s]

Also is there a plan to update create react app with workbox?

[jeffposnick]

Most likely, yes, though it would require some consultation with the c-r-a maintainers and would not happen until the v3 release of workbox-webpack-plugin is final.