So let's dive into that and let's start with TASC one identified a strategy we currently use in the
service work or so here which strategy is this.
Well let's analyze it.
We respond with something where we first look into our cash and see if we can find the requestor then
if we have a valid response we return it else.
If the response is null we return a fetch request where we simply reach out to the network with the
original request which we caught and then we take that response from the network store it in the cash
and return it.
So what is this strategy.
It's the cash fall back to network strategy.
We look at the cash first but if we don't find a response there we reach out to the network.
And besides that we all support any network response we get into the cash to add dynamic caching to
it.
That's kind of part of the strategy but the strategy would all work without deadline here.
So we could remove that and we would still have a cash fall back to strategy to network strategy.
So is the answer to the first task.
I'll put it below it.
It's cash fall back to network with dynamic caching if you want to add this optional.
But yeah we do store everything in the cash.
Let's move on to task to a network only strategy.
So for that here I will simply copy the strategy we already have cash and fall back and we'll comment
it out.
I just copied it so that we still have it here for reference.
So the goal is network only.
Well that actually is easy to implement we could ever remove the listener altogether because then we
reach out to the network any ways in our code and the next extremophile when we fetch files and so on
or we leave the eventless are here.
But then we don't respond with cash match.
Instead we respond by simply reaching out to the Web by simply sending a fecche request and then we
can still opt to store dead in the cache.
However it doesn't really make a difference because we're not really loading any friend from the cache
so he can't get rid of that and just returned the fetch request.
That's super simple.
Now let's save this and I changed you made a Jaspal but only edit this line so I don't need to bump
up the word in my service worker.
So let's just safety service worker go back to the assignment and there is always you can reload and
then simply close the tab and open one or application clear storage clear site data.
As I wrote in the instructions then reload everything and those you see service worker is registered
and the application still works.
And if we inspect this box you're the width at the height 310 that actually is five times my IP the
first two digits 1:54.
So that works.
So with that we got this set and we got our first assignments solved.
We always reach out to the network here for completeness sake let's see what happens if we go off line.
Unsurprisingly our application crashes because we have no cash fallback.
We always reach out to the network.
So this is a task he has solved a network only strategy.
I will add it above it so that we have there for reference network only.
Let's move on to task free.
A cash only strategy.
So back in the service worker we now work on this again.
No I will copy it and then comment it out the network only strategy and now I want to have a cash only
strategy.
Well that's simple too.
Instead of fetching here we was cashers and we see if we can find the request in our cash then we have
a function where I would get a response if we fail not if we find it under all circumstances and I returned
that response the response might be nulled though.
And to abbreviate it or to make it a bit shorter I can also remove that if all I'm doing is returning
the response in all circumstances.
I can leave out the then call and just call cash this match.
Now with that we only return stuff from the cash and if it's not on the cash well we can't use it.
So back to our application here.
If I reload it and then go to application clear storage clear site data reload again.
It's working under the network tab if I reloaders one more time.
We see everything is loaded from the service worker.
Now however on the second reload which we needed to do because the service worker is only now controlling
this page here we now see that a couple of things failed.
All the dynamic things only are static.
Cache works.
So if I told them that it works but it doesn't use you recalculate the width because it never got my
IP.
You also don't see it in the console log.
The reason for it is of course as I only reach out to the cache and if I don't find it there the request
is dead.
I don't let it continue to the network.
Now obviously this is an issue because the only things we have in the cache once we cleared it is the
part we cash statically during installation.
So we only have the static cash.
That's why the base styling is working why our application shell was loaded.
But it's also a reason why we don't have any icons and why we are not able to get the IP because all
that dynamic stuff isn't loaded.
So that's cash only.
And that's the downside of cash only.
Let's move on to task for replace it with network cache fallback strategy.
So now the goal is to first reach out to the network and only if that fails.
We want to reach out to the cash but we can't do that.
Let me first of all copy the old listener here and comment it out again so that we have it for reference
here but we don't want to use it anymore.
And now the goal is network fall back to cash.
Kind of the opposite of what we had at the beginning where we had cash fall back to network.
So here the goal is to respond with a request were to do well to the request we wanted to get.
But then we catch it if it fails if it does not fail it's all we wanted we got back the response.
But the fallback is to reach out to the cash.
So here in case we get some error we want to reach up to the cash so we could return cash has to access
all cash that we have.
And see if it got a hit in any of these caches.
So I'll check if the request can be found in any of the caches that actually is already all I don't
need to do much more than that.
Let's save this go back to the application again.
There to the application tab and Cleator storage clear to site data reload once to install the service
Rooker and reload a second time to put this under control of the service worker.
And now it's network fall back to cash.
Therefore on the network tab we see everything is fetched from the network in the end year which makes
sense because we first pass it to the service worker.
But then they we decide hey I want to make a fecche request.
Now let's see what happens if I go off line by taking this box for now reload.
It still works except for you dynamically loaded things because we're not doing dynamic caching right
now.
We have no code to put things into the cache once you got them but it still works.
You can see in the narrative.
Now we fetch most stuff from the service worker directly our network request failed but that's no issue.
We have it in the service worker.
That's why it's still in the cache which we load for the service worker.
That's why it's still working.
Now keep in mind the downside of this approach is that if you have a network which isn't just adequate
lable but which is somehow flaky which is gone after a while you have to wait until the request fails
and only then catch us executed.
So this might be too late.
It can lead to a bad user experience.
Now let's earn some bonus points by also adding a listener and make sure that we cache any responses
we get back to add dynamic caching back into the game again.
This is purely optional.
Feel free to pause now and try it on your own.
And now we do it together.
So here we got a response and then I want to store that in my cash right.
So what I can do is I can simply reach out to my cashiers and open the dynamic cash.
So if the dynamic name will change then here in there I have access to that cash in the function here
and all of cash I can put I want to put my event request URL and store the response which I got.
I also want to return the response and therefore I want to return cash this year which in the end will
bring back that response.
Here's one important thing though before we try this out make sure to call rest clone here.
Otherwise you're consuming the request and therefore you can store it in the cash.
So make sure to store a clone here.
Now with that let's go back to the application.
Let's go to clear storage clear site data reload.
Two times actually to make sure that everything is under control of the service worker and go off line
and you should see that the icons are available as is the adjusted size of the box here because in our
dynamic cache we now store all the things we all have fetched over the network.
These are just some bonus points but also nice practice.
So with that we got this task solved to onto task 5 here wants to replace the network cache fallback
strategy with the cache then network strategy.
Now this is a strategy where we have to write code both in our javascript file here on the front end
so to say so in the main don't just fall as well as in the service worker.
Do you remember how it works though.
Let's start in the main.
Jaiswal here we're fetching our data.
And actually after we do so we all want to see if we can already get the response from cache whilst
the network request is still on its way.
First of all we should check if the cashless object is available in the window so that we don't try
to access a feature you know which isn't supported by the browser.
If that's the case we want to reach out to the cache.
So hearable is something called caches match and look for it.
D you r l.
I'm going to save that you are all in a new variable here.
So let me quickly store it there and then use your l of course here in the fecche request and down there
where I try to find it in the cache.
Now then in function we get back to a response from the cache.
Now it could be null could also be successful if response is set.
So if you found something then I want to use it of course.
So if that is the case I want to execute that code here.
Well first of all though I need to return response Jason.
This will then lead to the next then block here where I get the extract that Jason data there I can
say console log from cache the data and here are old and want to use this code here to adjust a box
style maybe let's multiply with 10 here to really see a difference or maybe with 20.
And so really big so that we could see if the cache would win in the end.
So here I'm retrieving or regin that's just what the software gives us back from the data object we
extract that taking the first two characters from the AP multiplied and with 20 does what I'm doing
here.
So that's the cache case.
We also reach out to the network though and we want to make sure that the network responds always wins.
So what I'll do is create a new variable which will name network response received and I'll set it to
false initially.
Now once we get a network response though here in the fetch request handler.
Also true because now I know I got data from the network.
So I want to set it to true obviously.
And down there in the cache I only want to use my data.
If it's not true.
So if not network data received a response received because if we did receive one I certainly don't
want to override the data we got from the network.
So this line here should always win this one year should only be used if no network response is there
yet.
Now that's nice.
Re accessing the cashier we all want to add dynamic caching.
That's the part we write on the service worker and it's obviously optional but you're never going to
populate that cash if you don't at that logic.
So I'm going to copy the network fall back to cash rule here and I will add dynamic caching for network
excuse me for cash then network strategy because that's all we're doing here.
Some dynamic caching we do this by responding with something special.
We're responding with cash is open and I want to open my dynamic cash here so that I can write into
it.
So have a function here where we can access to cash them and in there.
I now want to return my fetch call to event request to let debt continue because always keep in mind
the service worker steps into the fecche coal we're issuing here in the main dodgiest fall.
So we definitely need to let this continue.
We do by returning fecche request.
However we also want to get access to the data out there.
So we have a function here where we get the response where I now want to store it in the cash.
So here I will have access to cash we have access to Frew dysfunction because we opened the cash call
put and for event request you are l.
By the way you could all the chest use request that would all the work I want to store a clone of the
response.
And of course return your original response so that we do pass something back for the fetch request
coming from the main dot js file.
Actually this will of course be run on any fecche request coming from anywhere in our application but
we're specifically writing it for this year.
So now we do have some place.
If we now save this let's go back and clear the storage in our application reload the application here
twice and now we see from cache undefined because it's not in there if I reload this one more time though
we see from cache it found something because too dynamic caching it was stored there.
What will also see though is that on the network we do fetch it from the network in the end which makes
sense because we have a cache Denn network strategy.
We'll see though that if I go off line everything breaks the reason for this is that in the service
worker we have no logic to return anything.
If we're off line we're not returning anything we're just storing something for requests we get.
So this is the part which leads up to the last task offers assignment where we want to differentiate
based on the you are l of the request which strategy we use so that for some of you or else we do return
a page we reached the final part of his assignment task 6.
There I now want you to use routeing or you are parsing to pick the right strategies for different types
of requests or requests targeting different view or else I want to implement to cache the network strategy
which we just added.
But I also wanted to add to cache with network Fulbeck strategy.
The one we had at the very beginning of the assignment and cash only strategy and a promise you can
fit all three of them into this simple project.
So you will need if else and else if statements to make sure you parse different view or else this is
probably the hardest part.
But in the end it only uses things you saw in the last lectures.
So feel free to jump back there to definitely try this on your own.
Here's my solution.
So we want to have cash the network for which kind of request would this make sense.
Well only for one request for this one here because cache then network mostly happens in our normal
javascript falls and there we only use it for this.
L this block here that's to cache the network block.
So therefore we should look for this you are L-N the service worker too and only use days.
I just want to store logic here for this URL.
So in the service worker here I will check in to see eventless her Ifti your L event request your l.
If we can identify this Eurail as part of the request Eurail it should actually be to complete your
Ehle But again just to be sure it's enough if it's part of Durell if debt is greater than minus one
it means we found something we got a hit and then I want to use this and just store something.
This allows me to then as the else case for example implement the cash then network fall back into cash
or network fallback logic we had at the beginning.
So let me copy that here from the very bottom and let's add it in the else block.
And of course I need to remove the comments.
So this makes sure that only for this you are l we just store it for all of our requests.
We actually try to find a response in the cash if we don't find one.
We reach out to the network Now we also were prompted to implement a cash only strategy though right
now we only got the first two now.
Cash only makes sense kind of for all the things we cash statically during installation because we know
these items will be in the cash right from the start.
So we can safely fall back to a strategy where we only fetched them from there.
These are also not assets where we expect regular updates.
So it's not a bad practice where it doesn't hurt to just get them from the cash.
The things we want to cash dynamically would be the Obert page and we may CSA as file it's using the
dynamic don't see us as follow for example which is not part of the strategy.
Cash things here.
So that is exactly what we're looking for.
We want to make sure that everything which is part of this array here is loaded with a cash only strategy.
So at Altes if case here where I want to look for this condition and I actually shared javascript snippet
a regular expression in the last lectures where we use just debt.
So feel free to simply reuse that of course.
There I simply create a new regular expression where we had backslash backslash B.
Then I would join my array of your else together.
So I will do that.
You are too static wups static files maybe is just dead arrays here we're passing to you at all.
Let's store it here.
And let's then use static falls here for at all but also at the bottom here and here.
You're an else if to join it to gabber.
So here we wanted to join with backslash backslash B pipe symbol.
So I was the wrong character pipe symbol backslash backslash B.
And thereafter add another word separator backslash backslash B and then simply test already when to
request your l.
This will find out if your L actually contains one of these requests.
We store statically now with dad check your in place we can add to cash only strategy here.
So we want to respond with just that.
So let's quickly add that to your like debt and we make sure that all these statically cashed files
are directly and only serve from the cache.
Let's go back to our application clear to storage there.
And reload it.
So now we're loading from cash already.
Now in the network we see that we're mostly loading stuff from our from the service worker.
We also see that some things are failing though.
Now the reason for this behavior that a lot of stuff is loaded from the service record but some files
just fail is simply the way to us else if condition works here.
It Right now consumes everything because there's one thing in this array.
This leading slash which is part of every u r l.
This is why this is true for every request you are all we get basically.
Now to fix this all get rid of this term solution here and simply add a helper function which all name
is in array there.
I expect to get a string and array.
And that in there I can simply whips in there I can simply loop through the array so I can check if
for var equals zero as long as I'm smaller than the array length.
I want to increment I.
And then I can simply check if array.
So the element I'm currently at if that is equal to string then I want to return true.
Otherwise if I go for the whole loop without a hit all returns false.
So now I can use it in array here and simply pass both went.
Request your L as the word I want to check for and then static files.
Now if there's emplace with this improvement here you should be able to go back to the application here.
Whip's cleared of storage reload my application the ones to install everything reload twice.
Now I can start at least back and with that if I now go back to off line mode it also still works.
Here you see the cache wins in the cache and network condition which is why the box is very high.
Because this is just what we do.
We fetch it from the cache first and we multiply with 20 there.
Remember if you go back to the main dot James fall here 20 years to case if he got the well from the
cache and of course if we're off line we got no average chance to getting it from there.
So this proves that this all works off line so does the rest of our application here to go back online
and reload.
Well then we see the box much smaller because now the network wins.
And in the network we see the majority of fetch from the cache except for our dynamic thing where we
have to cache then network condition so the network should win indeed.
So this is now all working was quite some work it definitely not an easy exercise but worth it.
And very important.
I hope you'll learn a lot and definitely keep on practicing these things.
I can only urge you to do so.
It's so important to understand the strategies.
Practice them in your own projects.
So do you really feel confident using them.