googlecodelabs / your-first-pwapp Goto Github PK

After they complete this code lab, what should they do next? Ideally I'd like them to do the push notification code lab.

It should also include deeper resources on fetch, caches, service workers, etc

Low pri - for after IWD

The following files aren't needed for the codelab and should be deleted to not confuse students:

• resources/final-gulpfile.js
• resources/package.json
• firebase.json
• generate-sw.js
• gulpfile.js
• index.html (in root only)
• make-zip.sh
• package.json
• server.js

I also believe that /images and /styles can be yanked, but will file a separate issue for those two.

In resources/step4/app.js, remove app.hasRequestPending, it isn't supposed to be there until step 7.

As of right now, it's on line 135.

Step 5 has us paste the following snippet into app.js:

// Save list of cities to localStorage, see note below about localStorage.
app.saveSelectedCities = function() {
  var selectedCities = JSON.stringify(app.selectedCities);
  // IMPORTANT: See notes about use of localStorage.

The comment above apparently refers to the comment below, which refers to... The first one? Something in the codelab itself?

I spent about five minutes reading through the first half of this step trying to figure out
which notes they were referring to. Then I finally gave up and went on to the next step, which involves pasting in a big comment... D'oh!

This was unnecessarily confusing. At a minimum, please combine these two comments into one, so they don't appear to refer to each other. "See note below" might prompt one to look lower in the codelab, if it weren't for the second comment, which confuses the issue.

When does it fire? How does it compare to 'install'?

"Ten seconds of milliseconds? What does that mean?"

"tens of milliseconds" seems like a quick easy fix

It's really tricky to debug your service worker.

We should create a nice tutorial that's got some gotchas in it.

It's not serving right now because it's in the code lab root directory as opposed to each of the step files.

We need to make sure that the sample code is up-to-date across our resources, in particular, any resources linked to in 'is service worker ready' resources list.

Also, can we organize our sample code noting the APIs that are used in them in a complete list? That way if someone wants to look at a great sample showing cache API, they can see that the sample matches what they are looking for.

I can pretty consistently get this to happen by alt+tabbing away from Chrome then back and then hovering over any body text. It sticks around indefinitely.

Confirmed on both Mac and Windows.

Clicking on the button generally fails; only clicking on the text succeeds.

I disabled bypass user engagement checks on my phone but was still never able to see a web app install banner for https://weather-pwa-sample.firebaseapp.com/final/

The console log will always display, because it comes before the conditional check to see if it should delete this cache

Existing line:

Copy app.js from the resources/step4 directory to your scripts folder.
Should read:
Copy app.js from the resources/step-04 directory to your scripts folder.

Suggested step:

To see how the fake weather data is rendered, uncomment the line below at the bottom of your scripts/app.js file
The call is already uncommented in the file.

The phrase 'bump cacheName' in Step 6 is assuming a lot of pre-knowledge. You're assuming people know you mean increment the string with the variable name cacheName at the top of service-worker.js.

Push notifications do not work in incognito mode and further the use of incognito mode for development is discouraged.

I think the best workaround is to use a development Chrome profiles and wipe them via chrome://settings/clearBrowserData. (This also has the advantage that the web server Chrome extension only needs to be present in the development profile.)

See also #15.

As a (bit) maniac programmer, I had put the service worker under ./scripts next to app.js

It took me a while to figure out that there was a notion of scope associated with the service worker script which is deduced from its URL path.

Thanks for the tuto!

Especially given that I am running this on localhost, which is never "offline", how can I test that all the stuff I did in step 6 actually had an effect?

Maybe I should be testing from my phone using some kind of localhost-to-internet tunnel?

if (e.request.url.indexOf(dataUrl) === 0)

could be

if (e.request.url.startsWith(dataUrl))

Every browser that supports service workers supports startsWith.

At the very beginning of step 2, the documentation suggests to Unpack the downloaded zip file. This will unpack a root folder (PWA-GettingStarted-codelab) but the zip (and unpacked folder) are named your-first-pwapp-master

This seems like a bit of documentation that needs to be updated.

Compare how friendly the readmes are for https://www.npmjs.com/package/idb and https://mozilla.github.io/localForage/

The confusing callbacks/promises mix in the localForage docs is a bit unfortunate; I wonder if there's a better alternative.

On your-first-pwapp/#8, there should be a note about having node installed (e.g., via Homebrew or otherwise) before trying to install the firebase-tools via npm.

Step 7 - debugging the 2 requests at once approach is really weird. Should I only see one request in the network panel or two?

Once from service-worker.js, once from :8887/service-worker.js

Chrome bug? Or something about this setup?

Confirmed on Mac and Windows.

In the tutorial, when it says:

...but in a production app, the latest weather forecast data would be injected by the server....

Could you please clarify a recommended way to achieve that? I mean, should I do that generating data into a script tag with the weather content (the first way I thought), or there's a better and recommended option?

According to the Firebase docs (https://www.firebase.com/docs/open-data/) the open data sets will be shutting down on March 30th.

Looks like https://openweathermap.org/api will work reasonably well.

Step 9 seems completely unworkable in its current form.

Domenic@Vectivus  ~/Dropbox/Programming/PWA-GettingStarted-codelab/work
$ firebase init

Error: Cannot run init, already inside a project directory:

C:\Users\Domenic\Dropbox\Programming\PWA-GettingStarted-codelab

Deleting firebase.json in the parent solved this.

The javascript adds listeners for butAdd, butAddCity and ButAddCancel, but only butAdd is in the html-file we're using. They will probably go into the div dialog-container later, but they're not there yet.

Adding

    <button id="butAddCity" class="dialogbutton"></button>
    <button id="butAddCancel" class="dialogbutton"></button>

in the dialog-container fixes the errors, and doesn't show them on the screen.

Worked on Mac, didn't work on Windows. I presume it's because my firewall is blocking incoming connections on 8887. A warning might be helpful.

weather-data of newyork not accessible

since it happens async, it's unclear what happened without this correspondence

Instead it moves to the previous/next page

At this point:

These errors:

I had to change it to "." when prompted (after solving #25).

Remove the images and styles directory from the root of the project, the files all exist in the individual step-0x folders.

Let's hang off on this one until after IWD

The file gets copied at step 2, not step 4, maybe it should just be moved to step-02/scripts/ or something else.

Where ever it gets moved, we also need to update the master doc as well

"Our app won’t work offline quite yet. We’ve implemented caching and retrieval for the app shell, but even though we’re caching the data, we’re still dependant on the network."

s/dependant/dependent/

Hi Pete,

Great progressive app tutorial. Just a quick suggestion - can you add a remove button to close the weather cards?

Step 2 says "we'll start with a new index.html" which folks think means create a new index.html. Really they should use the one from step-02

Step 4 tells us to uncomment app.updateForecastCard(fakeForecast);, but this isn't commented out.

Given that you can request more than one city in parallel, a single global flag on the app for whether there's a pending request seems like it will mess things up pretty bad.

In step 6.

The paths for .weather-forecast .icon, #butRefresh, and #butAdd in the inline.css file of the work folder result in the images not being rendered. The paths should direct to the parent directory since inline.css is in the styles directory (i.e., ../images/).

Of course, this may be OBE if inline.css is moved to the root directory by issue #4.

If you look in the "Test it out" part in section 6, you'll see that there's a break in the URL (it doesn't affect copying, but there's a break that's just causing a minor styling issue).

Screenshot:

This idea of bumping the cache name and deleting old caches really threw off my beta-tester. She also doesn't understand why we're doing this given the advice earlier to use an incognito window all the time.

Step 4 says, "uncomment the line below at the bottom of your scripts/app.js file."

However, it already is:

https://github.com/googlecodelabs/your-first-pwapp/blob/master/step-04/scripts/app.js#L178

... which is a little confusing.

Let's describe a bit better when the cacheName gets changed, and why that's important, and what's going on in the background if you don't update the cacheName.

Using self.caches throughout to be consistent with addEventListener would be good. Also, maybe explain that self in a service worker is analogous to window in the normal page would be helpful.