I'd like to implement service workers instant load for my website with the simplest implementation possible.
My idea is this - user opens webpage, gets cached version (app shell) and after the server return original content, it will be rerendered. Is that even possible? I couldn't find any example of that.
When the fetch event is called for the request then respond with the app-shell from the cache. and then wait Untill your server respond with the result then use postMessage to send the data to the browser. In your website's javascript add a message event listener and fills the data you receive, in the app-shell using javascript html. your app-shell must have some empty component that can be filled later.
For code reference refer to this link.
https://serviceworke.rs/strategy-cache-update-and-refresh.html
Related
Been looking into Service Workers and something that stuck out was the install life cycle. Since a service work is not available till after the web page is fist visited and the refreshed it means it would not be possible to use a service worker to serve client side only assets. Is this true?
I'm looking for a solution where A Web Application was able to collect user input as file contents and then have a service worker serve those assets to an IFrame. The use case being a browser based code editor like JSFiddle or Code Pen where multiple files could be created (JS, CSS, etc.) and the IFrame's requests are intercepted and provided for by the what was entered. That way things like ES6 modules could be split across multiple files all without having to save them to a back end server.
Is this even possible? And if so what is a good way to help the user through that first time refresh cycle as in the first visit such assets would be missing as the service worker hasn't been activated yet?
It is possible to use Service Workers to serve client-side only assets, but you'll need to handle the first load yourself, as the Service Worker won't be active until the page is reloaded.
high-level approach for handling the first load:
Store the user's input in IndexedDB, a client-side database that can be accessed from the Service Worker.
On the first page load, check if the user has any saved content in IndexedDB. If there's saved content, display it in the IFrame directly.
If there's no saved content, display a default placeholder and register the Service Worker.
Once the Service Worker is registered, it can intercept requests made by the IFrame and serve the content stored in IndexedDB.
When the user makes changes to their content, store the updates in IndexedDB, so they persist even if the user closes their browser.
This should ensures that the user can use your app even if the Service Worker isn't available, and the Service Worker can take over once it's been registered.
on MDN Web Docs you fill information on using Service Workers and IndexedDB together in the Service Workers API documentation
I just want to write a small script that does Foo() whenever I receive a push notification from my browser(chrome). I tried to find some stuff out there but all I found was how to send said notifications, but I only want to receive them. Anybody can lead me in the right direction?
I do not own the backend that sends the notifications
There is no frontend, its notification from the browser
I am currently trying with a browser extension, but cant access the notification. I do not know if browser extension is the way to go, that should be clear from my initial post.
If the question is about intercepting notifications that are generated on the web page with the Notification API, this answer explains how: Intercept HTML5 Web Notifications in a browser environment
To sum it up, it consists in the creation of a Proxy as a wrapper of the native Notification in order to hook into its constructor and execute arbitrary code.
If the question is about intercepting Push Notifications then it is impossible because they are based on the Service worker. You can't hook into the service worker, and you can't register your own service worker without overriding the existing one (which will break the web page), as stated in the documentation:
If there is an existing service worker available, the new version is
installed in the background, but not yet activated — at this point it
is called the worker in waiting. It is only activated when there are
no longer any pages loaded that are still using the old service
worker. As soon as there are no more pages to be loaded, the new
service worker activates (becoming the active worker).
When using a service worker to handle a request chrome actually resubmits submitted forms when I hit the back button after I have navigated away from the page by clicking a link.
Without a service worker the default behavior in chrome is to show a cached version of the response I got when I submitted the form.
With a simple service worker that just handles the request by using fetch() chrome actually replays the request when I hit the back button instead.
Is there any simple way to make service workers behave the way chrome does by default?
Tried the same thing over a year ago and then I concluded that it might be a bug, but since it's still like that I guess it's supposed to be like that.
I'm running into similar problems with back/forward navigation in Firefox. The best thing I've found to do is to sniff the request.cache param for 'only-if-cached' or 'force-cache' and to avoid trying to fetch in the first place.
There's some more documentation here about request.cache but it doesn't really document use for an incoming request to a service worker fetch handler properly.
is an ajax call made in componentDidMount supposed to freeze the page for a couple of seconds? I can't click or select anything until the ajax call completes, it's only retrieving about 3MB of data. I think the entire page finishes rendering but for some reason it just freezes while the date is being retrieved.
Any ideas on why this is happening?
You can use Web Worker for such purpose. It will run in a separate thread, so it won't freeze your UI behavior.
But notice:
You can run whatever code you like inside the worker thread, with some
exceptions. For example, you can't directly manipulate the DOM from
inside a worker, or use some default methods and properties of the
window object. But you can use a large number of items available under
window, including WebSockets, and data storage mechanisms like
IndexedDB and the Firefox OS-only Data Store API. See Functions and
classes available to workers for more details.
I'm currently designing a MEAN.js web application, and for some reason, whenever I refresh the page on a route or window.reload, it does not rerender the page, but only returns the JSON file found at that current route.
For example, when I'm at localhost:8080/people:
If I click here from the main page, I get
But if I hit refresh or reload the page for whatever reason I get
Does anyone have any idea why this is happening and how to fix it?
Presumably you are using what Angular call's html5Mode routing.
This uses pushState and friends. These are browser features designed to allow you to build a web app which has what appear to be separate pages with unique, real URLs but when you change the page you actually modify the DOM of the current page (to State B) instead of loading a new one from scratch.
The design intention for pushState and friends is that if you request the unique, real URL that maps onto State B then the server will provide the browser with the HTML for State B directly.
This means that:
if you arrive on the site without going to the homepage first, then you
load the content you are trying to load directly (which is faster than loading the homepage and then modifying it with JavaScript).
if you arrive on the site without JavaScript working (which could be for many reasons, then everything still works. See also Progressive Enhancement and Unobtrusive JavaScript.
What you've done wrong is that your URLs are mapping onto your JSON based API instead of server side processes that generate the pages.
You need to write the server side processes. You could consider using the Accept header to allow them to share URLs with the API (so the server returns either JSON or HTML depending on what the client says it accepts).