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

Recap for v1.0.0-canary.HEAD #46

108kb opened this issue Jul 9, 2019 · 3 comments


2 participants
Copy link

commented Jul 9, 2019

So basically we have 3 main problems that previously I was tell it here.

The Polling API

a.k.a Scheduler, the Alarm.


Our v1 was a "Subscription management" and the core of feature was a "reminder". It should remind us––as a user––like "Pay Spotify in next 7 days". By default, we set reminder H-7 before bill time.

The problem was, this app is should be offline-first in mind. We should place "offline" on top of anything.


Look at Twitter Lite (and its architecture). They also use Web Push Notification.

Based on my researching on their serviceWorker file here and here, they use self.registration.pushManager.subscribe() for "listening" Push event from server, so we can "show notification" even users doesn't open our app.


All we want is a "polling". Service worker has 4 main lifecycles:

  • Installing
  • Activated
  • Idle
  • Terminated or Fetch/Message

My worry was on "Idle" lifecycle. Does our serviceWorkers went to "Terminated" or "Fetch/Message"?

My logic was: "If we can subscribe Push Event from server, it means, we can doing something on that". Imagine like this:

self.addEventListener('push', function (e) {

  // this is a regular Push Notification code
  e.waitUntil(self.registration.showNotification('Regular notification', {
    body: 'Push Notification!'

  // add our polling here? e.g: setInterval(fn, ms)

This is still my hypothesis, I will create some PoC as our serviceWorker playground

Bad DX

We will create a serviceWorker playground to test our tinkering in separate project for efficiencies. This is not a silver bullet, but I think this is our best option.


Yes yes I know a PWA has ability to Add to Home Screen, works offline, etc etc etc. But maybe our users don't, we need to "educate" them that our app is "installable" and can works offline.

Current state

I have place it on "drawer" the "Install aplikasi" link, that only show when user never install the app before (or as long as there is @nadya:a2hs key in localStorage with true value.

Screen Shot 2019-07-09 at 22 54 15

I don't know does serviceWorker/web have API to check "does user uninstall our app?" so we can flush some datas by us.


We can rely on "Toast" component to "educate" user, like: "New version was available, refresh?", "This app can works offline", etc etc.


Web is unique, every users has different browser version, as our app––a web app––rely on browser. We need to handle is users browser support serviceWorker? Is users browser support Add to Homescreen? etc etc.

I think there is no shim for this. We can't using polyfill for this because the API is communicating directly between OS-level & Browser-level. The best way to solves this is by "telling" it. Just tell it, like:

  • This app is cannot work in Incognito mode, please blablabla
  • This app is cannot be installed on your device, please blablabla
  • This app is cannot send notification to your device, please blablabla
  • etc etc etc

Compatibility I think was a main reason why Electron exists on desktop-level, and why React Native (or other hybrid mobile app) exists on mobile-level.

To prevent our focus lost, this is some highlights:

  • Polling ability on serviceWorker (Under consideration. See [this]. #47 (#46 (comment)))
  • DX while developing with and using serviceWorker. #48
  • App compatibility, so users feels same experiences across devices

@108kb 108kb added this to To do in v1 via automation Jul 9, 2019


This comment has been minimized.

Copy link
Member Author

commented Jul 10, 2019

Hypothesis of The Polling API:


This comment has been minimized.

Copy link

commented Jul 11, 2019

I’ve been check the compatibility for IndexDB, that’s work in incognito with Chrome.

  • This app is cannot work in Incognito mode, please blablabla. (Work on : Version 77.0.3847.0 (Official Build) canary (64-bit))

I’ve been try & test the Hypothesis

we need to handle registration status of service worker before we run the pooling.


This comment has been minimized.

Copy link
Member Author

commented Jul 11, 2019

Yeah absolutely. And maybe you can notice the browser team (e.g: Chrome) to inform that our interval was still runs even the serviceWorker was unregistered

@108kb 108kb closed this Jul 16, 2019

v1 automation moved this from To do to Done Jul 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.