Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gatsby-plugin-offline] [gatsby/cache-dir] Fix various offline and caching issues #7355

Merged
merged 22 commits into from
Aug 21, 2018
Merged

[gatsby-plugin-offline] [gatsby/cache-dir] Fix various offline and caching issues #7355

merged 22 commits into from
Aug 21, 2018

Conversation

vtenfys
Copy link
Contributor

@vtenfys vtenfys commented Aug 15, 2018

Changes made:

  • <div> is replaced with <span> in gatsby-plugin-offline's app-shell.js to prevent an edge case in Chrome, where the the outer element's class attribute is unset despite its className being set in the VDOM, if the page was loaded from the offline shell.
  • A call to getResourcesForPathname was fixed - previously this prevented later code from calling since Promise.all(pathnameResources) would never resolve.
  • Styles are now searched as well as scripts when caching resources, and these are all cached regardless of whether they are included in pageResources.
  • Styles are also now searched in get-resources-from-html.js.
  • The offline shell and custom 404 page are now also scanned for resources when considering critical file paths.
    • get-resources-from-html.js is modified so that if a custom 404 page doesn't exist, an empty array will be returned.
  • A glob for Webpack chunks is added to the precache options, as these are sometimes loaded from other chunks and therefore not detected by getResourcesFromHTML, causing errors to occur when trying to navigate to another page when offline (if they haven't all been cached).
  • The navigateFallbackWhitelist regex is modified to prevent loading the offline shell if the URL ends with ?no-cache=1 or &no-cache=1.
  • sw.js is patched to include search queries when matching URLs against navigateFallbackWhitelist. Unfortunately I couldn't find any options to enable this, so patching appears to be the only way until a change is made upstream.
    • An error is thrown asking the user to report an issue if the patch fails - this will cause the build to fail, but will avoid confusion in the long run if the patch stops working.
    • I checked the ignoreUrlParametersMatching options, but it's for ignoring differences, e.g. between /page/ and /page/?utm_source=github, not for disabling caching or fallback.
  • JSON and CSS resources are cached at runtime.
  • page-renderer.js now checks for this.state.pageResources.json, since errors were previously occurring even when this.state.pageResources existed due to the missing JSON data.
  • When a page isn't found, an attempt is made to load it directly, in order to display a proper error message, i.e. 404 or offline error, or simply load it directly if it's available online (e.g. /admin/ for CMS, which is not directly part of Gatsby).
  • A clause has been added to an if statement in production-app.js to prevent the 404 showing until an attempt has been made to load the page directly
  • onServiceWorkerInstalled is now delayed by 100ms, since it was being called before the fetch event listeners were added, thus preventing resources from being cached. Unfortunately I couldn't find a programmatic way to do this (other than more patching of sw.js, which is less than ideal).
    • It might be worth increasing this to 500ms, since at 100ms it could still fail for more complex sites (despite working at as low as 20ms in local testing). Thoughts?
  • checkIfDoingInitialRenderForSW is removed from loader.js as it was causing the SW to be removed when navigating to a nonexistent page, even if the website had not been updated, causing it to stop working offline entirely - regardless, it is no longer needed with the other changes made.
  • README for gatsby-plugin-offline is updated to match the latest default options.

Closes #6212, Closes #7053, Closes #6688, possibly others

@KyleAMathews
Copy link
Contributor

KyleAMathews commented Aug 15, 2018

Deploy preview for using-postcss-sass failed.

Built with commit 4eb02cd

https://app.netlify.com/sites/using-postcss-sass/deploys/5b75433b3813f010edac0916

KyleAMathews
KyleAMathews previously approved these changes Aug 15, 2018
Copy link
Contributor

@KyleAMathews KyleAMathews left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! Very through! I'll give it a more through review, hopefully later, but thanks!

@@ -1,7 +1,7 @@
{
"name": "gatsby-plugin-offline",
"description": "Gatsby plugin which sets up a site to be able to run offline",
"version": "2.0.0-beta.9",
"version": "2.0.0-beta.10",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the version gets bumped automatically as part of deploys so please remove this

@gatsbybot
Copy link
Collaborator

gatsbybot commented Aug 15, 2018

Deploy preview for using-drupal ready!

Built with commit 4eb02cd

https://deploy-preview-7355--using-drupal.netlify.com

@gatsbybot
Copy link
Collaborator

gatsbybot commented Aug 15, 2018

Deploy preview for gatsbygram ready!

Built with commit 4eb02cd

https://deploy-preview-7355--gatsbygram.netlify.com

@KyleAMathews
Copy link
Contributor

KyleAMathews commented Aug 15, 2018

Deploy preview for image-processing failed.

Built with commit 03138384e2592f0abca8626f22822d4fd213215e

https://app.netlify.com/sites/image-processing/deploys/5b7764dac6aed6786a016d16

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 15, 2018

@KyleAMathews thanks! I'd normally agree with small PRs, but the bugs were all so interdependent that I felt they would become fragmented with separate PRs, which might result in some of them reappearing after others having been fixed or some being forgotten. Looking forward to your full review though!

@KyleAMathews
Copy link
Contributor

Deploy preview for gatsbyjs failed.

Built with commit 15ee192

https://app.netlify.com/sites/gatsbyjs/deploys/5b745f394ed62f238b914384

@KyleAMathews
Copy link
Contributor

KyleAMathews commented Aug 15, 2018

Deploy preview for gatsbyjs failed.

Built with commit 4eb02cd

https://app.netlify.com/sites/gatsbyjs/deploys/5b75433a3813f010edac090a

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 15, 2018

By the way, I just checked #7268 after rereading your comments on #6212, and it's a different issue to the one I was fixing -- #7268 serves the 404 page when running gatsby serve, whereas this PR is about handling what happens when the offline shell can't load the specified page, since the shell would previously try to handle all pages matching the regex /^.*([^.]{5}|.html)$/ regardless of what's happening on the server. Apologies, I see it's not just changing the behaviour of gatsby serve - I'll try to check tomorrow to see how custom 404 pages are handled with these changes. I believe they should work fine, but I'll need to make sure there aren't any edge cases or odd behaviours.

Update: I've just pushed another commit which fixes some issues with regards to the changes in #7268. There are some more issues I've just noticed - pushing another commit shortly!

Update 2: I'll need a bit more time to get this fixed - should be ready later today

@wKovacs64
Copy link
Contributor

@davidbailey00: Nice! ❤️

@jlengstorf: A lot going on here, but some of it may address some or even all of the things pertaining to gatsby-plugin-offline that we went over in our pairing session last week. (Did you end up creating that issue somewhere? We may want to link here if so.)

@jlengstorf
Copy link
Contributor

@wKovacs64 I... definitely did not create that issue. I still have it written in my notebook to capture. 😬

Thanks for the heads up!

@wKovacs64
Copy link
Contributor

@jlengstorf Oh no sweat, no rush. Thanks!

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 16, 2018

I've fixed the remaining issues with regards to 404 pages, including a bug which #7268 introduced, and I've updated the changelog to reflect these fixes. Code should now be ready for a review! 😄

@vtenfys vtenfys changed the title Fix various offline issues [gatsby-plugin-offline] [gatsby/cache-dir] Fix various offline and caching issues Aug 16, 2018
@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 16, 2018

Just pushed a commit which throws an error if the sw.js patch fails - otherwise this might stop working in the future without users knowing why a problem is occurring.

@KyleAMathews
Copy link
Contributor

Not necessarily for this PR but it'd be great to add this in the future #7382

@dfmarulanda
Copy link

It wasn't a problem of azure, because it is a server as a static website. The problem only happened when in the production build served by Azure. It never happened on the local build. @davidbailey00 I'm uploading the public folder because I use it to make a continuous deployment using my GitHub repo. It's fixed, but it was a weird bug generated in the last update.

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 29, 2018

@KyleAMathews @ssmith-wombatweb @dfmarulanda @jlengstorf perhaps we could have a runtime console warning after A page wasn't found for ... if it detects a page with the same name but different casing? We won't fix the Netlify+uppercase edge case but then it should be clear why it's not working.

On the note of this, I just noticed that URL search queries aren't always kept when redirecting to ?no-cache=1 - given the Netlify problem, https://www.simeonsmith.me/coding-with-kids/2018/08/10/crab-trap-alpha?no-cache=1 should keep adding &no-cache=1 when reloading. A better demonstration of the problem:

  1. Go to https://wizardly-babbage-0faa32.netlify.com/ and wait for the SW to install

  2. Then go to https://wizardly-babbage-0faa32.netlify.com/admin/?somequery=1 (should be handled by the service worker)

  3. Expected behaviour: redirects to https://wizardly-babbage-0faa32.netlify.com/admin/?somequery=1&no-cache=1

    Actual behaviour: redirects to https://wizardly-babbage-0faa32.netlify.com/admin/?no-cache=1

@KyleAMathews
Copy link
Contributor

Yeah, that's the sort of warning I was thinking of.

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 29, 2018

@KyleAMathews Alright, I'm still doing work experience until the end of this week but I can try fixing that tomorrow evening, along with the other bug.

A warning should be easy to implement, although the bug I just discovered might take me a bit longer - it only happens from external links or direct URL entry, not from <Link>s; I think I vaguely understand why but I'll need to play around a bit. I can submit these as separate PRs since they're not directly related, unlike the issues from #7355.

(Also, unrelated to these issues but the company I'm doing work exp at seems impressed by Gatsby and is considering rewriting their current sites on legacy stacks using it 😄)

@mjoynes-wombat-web
Copy link

Just coming back to confirm that changing that to lowercase solves my issues on Netlify.
https://www.simeonsmith.me/coding-with-kids/2018/08/10/crab-trap-alpha

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 30, 2018

I've thought of a better solution than showing a warning - we can use Gatsby's global window.page.path to get the canonical path rather than using the page URL, which means that even if the page is loaded from a different location (potentially completely different), it can still find the resources. I'lll work on this tonight

@KyleAMathews
Copy link
Contributor

(Also, unrelated to these issues but the company I'm doing work exp at seems impressed by Gatsby and is considering rewriting their current sites on legacy stacks using it 😄)

Nice! :-D

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 30, 2018

I've thought of a better solution than showing a warning - we can use Gatsby's global window.page.path to get the canonical path rather than using the page URL, which means that even if the page is loaded from a different location (potentially completely different), it can still find the resources. I'lll work on this tonight.

Just to update everyone, I've made some progress on this by replacing window.location.pathname with window.page.path in production-app.js but currently trying to understand how the <PageRenderer>'s properties are set, since modifying just production-app.js doesn't fix the issue.

Edit: I meant RouteHandler rather than PageRenderer

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 30, 2018

cc @KyleAMathews @jlengstorf @m-allanson I'm really struggling to understand where RouteHandler gets its props from, can someone help me out? I'm testing by making a copy of the about folder to about-test, to see if I can get it to load correctly using the canonical path (window.page.path) rather than the URL's actual path.

If I log the props...

image

...it's clear that the location prop is set from window.location:

image

But after running a trace I still have no idea how it gets these props. The element itself is created at line 126 (in my local code with added console.logs) when the renderer function is called:

image

...since it renders NewRoute, which wraps the RouteHandler element. It's clear that the only prop passed is the path prop:

image

All function calls between line 126 and the RouteHandler constructor are React calls, which can be seen via the console trace:

image

All the other calls are higher-level and have no mention of location or anything like that. My guess is that Reach Router must be adding the props, but I don't understand it well enough to know how this works... Could someone help me out please?

@KyleAMathews
Copy link
Contributor

@davidbailey00 could you copy your previous comments over to a new issue? This one is getting rather lengthy :-)

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 30, 2018

@KyleAMathews sure, in hindsight I probably should've done that earlier :)

@dfmarulanda
Copy link

I updated gatsby today and now im getting

These dependencies were not found:

* @babel/runtime/core-js/get-iterator in ./node_modules/gatsby-plugin-offline/gatsby-browser.js
* @babel/runtime/core-js/promise in ./node_modules/gatsby-plugin-offline/gatsby-browser.js

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 31, 2018

@dfmarulanda Thanks for the heads up, I'll check this out.

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 31, 2018

@dfmarulanda hm, I'm unable to see what the issue is here since everything works locally for me... Can you try upgrading all packages again, and running yarn (or npm install) just to make sure any new dependencies are installed? If that still fails, can you output your package.json?

@dfmarulanda
Copy link

I already deleted node_modules and then yarn install. Also tried to add @babel/runtime by itself.

{
  "private": true,
  "scripts": {
    "build": "gatsby build",
    "develop": "gatsby develop",
    "lint:es": "eslint --ignore-path .gitignore \"**/*.{js,jsx}\"",
    "lint:style": "stylelint \"src/**/*.scss\"",
    "lint": "yarn lint:es && yarn lint:style",
    "format": "prettier-eslint --write \"**/*.{js,jsx,json,css,scss,md}\""
  },
  "dependencies": {
    "@babel/runtime": "^7.0.0",
    "@reach/router": "^1.1.1",
    "babel-eslint": "^8.2.6",
    "babel-plugin-styled-components": "^1.5.1",
    "fbjs": "^0.8.17",
    "gatsby": "^2.0.0-rc.7",
    "gatsby-plugin-canonical-urls": "^2.0.0-rc.1",
    "gatsby-plugin-drift": "^1.0.0",
    "gatsby-plugin-favicon": "^3.1.2",
    "gatsby-plugin-offline": "2.0.0-rc.0",
    "gatsby-plugin-react-helmet": "^3.0.0-rc.1",
    "gatsby-plugin-styled-components": "^3.0.0-rc.1",
    "gatsby-plugin-typography": "^2.2.0-rc.2",
    "grid-styled": "^5.0.2",
    "object-assign": "^4.1.1",
    "prop-types": "^15.6.2",
    "react": "^16.4.2",
    "react-dom": "^16.4.2",
    "react-emotion": "^9.2.4",
    "react-helmet": "^5.2.0",
    "react-router-dom": "^4.3.1",
    "react-typography": "^0.16.13",
    "styled-components": "^3.4.5",
    "styled-media-query": "^2.0.2",
    "typography": "^0.16.17"
  },
  "devDependencies": {
    "emotion": "^9.2.6",
    "eslint": "^4.19.1",
    "eslint-config-airbnb": "^17.0.0",
    "eslint-plugin-import": "^2.13.0",
    "eslint-plugin-jsx-a11y": "^6.1.1",
    "eslint-plugin-react": "^7.10.0",
    "prettier-eslint-cli": "^4.7.0",
    "stylelint": "^9.4.0",
    "stylelint-config-idiomatic-order": "^5.0.0",
    "stylelint-config-recommended-scss": "^3.0.0",
    "stylelint-scss": "^3.2.0",
    "webpack": "^4.16.4",
    "webpack-cli": "^3.1.0"
  }
}

@vtenfys
Copy link
Contributor Author

vtenfys commented Aug 31, 2018

You've got an old version of gatsby-plugin-offline which isn't updating because for some reason it doesn't have the caret (I can see that all other packages do). rc2 is the latest version; can you add the caret and then upgrade again?

image

@dfmarulanda
Copy link

Yeah. It seems it was the problem. Thanks!

@dfmarulanda
Copy link

I made an update yesterday and it seems it's broken again. I cannot figure out what's happening with it. You can check out my website at https://crowdswap.com

@pieh
Copy link
Contributor

pieh commented Sep 6, 2018

@dfmarulanda can you create new issue with more details of your setup - including output from gatsby info?

@vtenfys
Copy link
Contributor Author

vtenfys commented Sep 6, 2018

@pieh actually I'm just checking this out and the problem seems to be because the public folder isn't gitignored, so might not need a new issue

@vtenfys
Copy link
Contributor Author

vtenfys commented Sep 6, 2018

@dfmarulanda I've just checked and confirmed my above comment - you're not ignoring the public folder so the wrong files are being generated, causing additional errors. Please add public/ to your gitignore and then delete the folder, and commit all changes. Working demo: https://clever-villani-54e8ff.netlify.com/

Also, as @pieh said, in the future please create a new issue since GitHub's TTFB on this page is getting ridiculous 😀

@dfmarulanda
Copy link

dfmarulanda commented Sep 6, 2018

But i don't understand why i have to gitignore the public folder. I use it as continous deployment to my website using azure web apps. I always delete the public folder before publishing. Why it would be the problem?

PD. Azure is connected with my public folder in my github repo.

@vtenfys
Copy link
Contributor Author

vtenfys commented Sep 6, 2018

Your HTML file is referencing JSON resources which don't exist on the server:

image

image

This is causing Gatsby to think that it shouldn't handle the page, since it can't find the resources, and so it tries loading the page directly. Since Gatsby does actually handle the page, it does the same thing again and again, forever.

I always delete the public folder before publishing.

In that case I think you're doing something wrong - after I ran rm -rf public .cache node_modules/.cache && gatsby build && gatsby serve, I had no problems. Even if you get this to work, it's considered bad practice to upload built files to git - you should use your Azure CI to build the Gatsby site, rather than doing it locally which should be done for testing only.

@dfmarulanda
Copy link

OK. I'll try to change my deploy process. It's super easy to do it using netlify, aws, heroku, but there is no an azure plugin. There is a docker plugin working in the latest version of Gatsby?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
10 participants