I'm currently using grunt-contrib-watch which has livereload built in. This is working fine and on saving a file Chrome reloads page (with the help of live reload browser extension).
However there is sometimes a brief delay in reloading a page. Sometimes I'm left staring at a page not knowing whether it just hasn't reloaded yet or whether a LESS/CSS change hasn't worked. Is it possible to have some kind of notification (like a beep) to tell me when the page has been refreshed?
Might want to take a look at Grunt Notify.
This allows you to set specific notifications for each task you are running and allows for a large amount of configuration.
Example task at the top of your grunt file:
grunt.initConfig({
notify_hooks: {
options: {
enabled: true,
max_js_hint_notifications: 5,
title: 'Notifications'
}
},//other grunt tasks here
});
Related
So we recently changed our landing page from create-react-app to using Next.js. Our old create-react-app had a basic default service worker registered on users browsers.
Whenever I switched over to our new Next.js website, we realized that users who had been there before would continue to get a crappy cached version of the old website.
I've found a couple of discussions talking about this issue already, but neither solutions seem to be working for me. Those two discussions are:
A website is not refreshing because of caching of service worker, after switching from React to Next.js. How to force update?
https://www.asapdevelopers.com/service-worker-issue-nextjs-framework/
Both of these solutions essentially consist of adding a new service worker file to your Next project with some code to delete the existing service workers. That code looks like
if ("serviceWorker" in navigator) {
window.addEventListener("load", function () {
navigator.serviceWorker.getRegistrations().then((registrations) => {
console.log("--");
for (let registration of registrations) {
registration.unregister().then((bool) => {
console.log("unregister: ", bool);
});
}
if (registrations.length) {
window.location.reload();
}
});
});
}
So i've tried this. My old service worker was served via a file at route OUR_URL/service-worker.js. I added a public directory to my Next project and added a file with the same name and the code above to my project. I then linked this file in my _document.js and can confirm that it runs, as well as I'm able to find it on my Next.js site. The URL for both the new and old files are identical. Unfortunately though, it looks like the issue persists.
In one of the other articles linked above, it also mentions putting this file in the root directory of your Next project. This doesn't make much sense to me as it isn't then being served in anyway that I'm aware of, but I gave this a shot as well, still with no luck.
Anyone have any idea what I might be doing wrong here, or what I could do to fix this? Essentially we just want to force remove any and all old service worker so that our new website loads correctly.
Service workers are (at least generally) registered via the site itself and not automatically found by browsers (at least not yet).
This code (unregistering all service workers for the domain) should go in whatever is being sent from next.js to the browser (e.g. index.js). If you put this on your home page all users going there should have the problem resolved. If you have reason to suspect (based on traffic data) that users have other pages bookmarked you might want to include this in a universal bundle or footer.
I'm working on a website on nextjs but the Link component and the router is kinda driving me crazy. When I click on a link it has an horrible delay before accessing the page and then if you use the browser back button the page don't change, just the url.
Here is the link of my site, don't really know what is happening actually.
https://next-madeleine.tmsssss.vercel.app/
It is common for Next.js and other frameworks as well to be slow in development time. As I can see and confirm in your production live website, the links work well, even great. That it because in development there are certain tools and packages being used by Next.js and webpack to compile on-fly the code. Those tools are disabled and removed in a production build of course, and the pages are cached by Next.js.
So, try to run npm run dev and compare it with npm run build, followed by npm run start
NextJS runs getInitialProps, getServerSideProps and getStaticProps every time you link to a page, which might be time consuming. You can skip this by shallow routing your page. Link accepts a boolean prop called shallow={true}.
<Link href='/your-page' shallow>Your Page</Link>
With Next's router.push:
router.push('your-page', undefined, { shallow: true })
Read more about Shallow Routing - https://nextjs.org/docs/routing/shallow-routing
I am developing an iOS app that mainly loads my web pages in WKWebView.
Things were fine so far before I start facing a weird issue with one of the CSS file not loading.
The font-awesome.css file is not loading, generally it gets loaded on the very first page call. In my knowledge nothing has been changed on the server side that could affect loading of font-awesome.css file.
I am intercepting request by implementing following function in iOS app code. But for the first request I just do decisionHandler(.allow) because I don't want any interception for the first request.
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction,
decisionHandler: #escaping (WKNavigationActionPolicy) -> Swift.Void) {
// For the first request it will go as is
decisionHandler(.allow)
}
Once the first page gets loaded on WKWebView the font-awesome.css file didn't get loaded hence some font icons are shown as squares on the page.
After spending some time on this issue I tried to put a delay on calling decisionHandler(.allow) as follows and then it starts loading the font-awesome.css file:
DispatchQueue.main.asyncAfter(deadline: .now() + 0.150) {
// I just added a delay of 150 ms and it starts loading the css file.
decisionHandler(.allow)
}
For me currently its very confusing to figure out the relation between putting a delay and loading of the css file.
I need suggestion on this behavior why its happening or is there anything else due to which this is happening and I am just doing a work around by putting a delay.
Some more updates:
I have an Android app also that is loading same web pages in WebView and that is working fine.
I check the IIS logs by sending the request with and without putting the delay. With the delay I an clearly see in IIS logs that it loads the font awesome as follows, but in without delay I don't see this entry in IIS logs:
2020-11-23 13:44:36 10.100.2.72 GET
/Content/fonts/fontawesome-webfont.woff2 v=4.5.0 80 - 10.100.0.111
....
Let me explain a little bit:
I'm currently using a CDN to push reloads, due to some issues I've had with Trigger's reload infrastructure. For some reason, the latest reloads I'm pushing don't seem to be getting through to the app.
I don't 100% understand how the reloads work (I suspect they go by some kind of queue in the order you push reloads), but my suspicion is that it's because one of the reloads in the queue got overwritten or deleted from my CDN, so the .apk (it's an Android app) is looking for an update that no longer exists on the server, and isn't skipping ahead to future updates.
Anyway, the question is: can I wipe the slate clean somehow, so that the apps stop looking for that reload?
Or, is there a way to force all apps to get the latest pushed reload? I know the reloads only work with changed files, but is there a way to say "this is the latest official version" and force apps to reload to that one?
UPDATE: I think it might have something to do with the active configuration I'm pushing to. Is there any way to determine which config ID (i.e. the one that most users are using) in the Reload panel matches up to which reload or manifest file I have on my CDN, so I know which version those users are on?
First, a little background: when a device checks for a Reload update, it contacts the Trigger.io server to find out what the most recent applicable Reload update is, and where it is stored.
In your case, that will point the device towards a manifest file stored in your CDN, and the files referenced from it will be downloaded and swapped in.
So, the apps will automatically pick up the latest pushed Reload. If a Reload update is deleted or corrupted in the CDN, we still go back to the Trigger.io server so fixing the problem is just a case of re-pushing a newer Reload update.
There's no "out-of-the-box" way to connect which manifest files correspond to which config ID. One approach would be to install the app built from the relevant config ID, and let the Reload update occur. If you look at the debug log output as that Reload is happening, you can see what files are getting downloaded, and why.
I have an ASP.NET 3.5 web application written in VS 2010. I have an aspx with a script reference to a .js file that resides in a Scripts folder.
<script src="Scripts/jquery-1.4.1.min.js" type="text/javascript"></script>
<script src="Scripts/HeaderControl.js" type="text/javascript"></script>
Within the .js file I'm using jQuery to do some various operations, one of which was simply a debugging statement that used alert to spit out a value on the page so I could see what it was.
if ($) {
$(document).ready(function () {
$("input[id='q']").click(function($e) {
alert("clicked");
});
});
}
This all worked great until I went to remove the debug statement (the alert "clicked"). Upon completely removing it from the .js, I rebuilt the project, hit F5 to run it on my localmachine, but as soon as I clicked upon the input tag above the alert still popped up and said "clicked". I tried one thing after another trying to get the web app to realize that the .js had been changed, but it kept displaying the alert every time that I'd click on the input tag. I finally decided to rename the .js to something completely different, at which time the web app realized that the .js had been changed and it quit displaying the alert when I'd click upon the input tag.
So why was this .js file being cached? It's a very annoying behavior and I'd love to know what exactly was causing it. Any help would be appreciated. Thanks!
EDIT:
Browser was IE7. I didn't check to see if it did it in Mozilla as well. Regardless, I've done at least a 100 different .js files and I've never noticed this behavior before. The only difference for me is that this .js is in a web app, whereas usually I'm creating them in ASP.NET web site projects.
You need to Shift + Refresh, or, just clear your browser's cache.
This is normal behavior:
Javascript and CSS files do not even check for a new version (an If-Modified-Since request) if the old version is still valid according to the cache headers in the response sent the first time.
I believe that if you put in any query string, even just ?, at the end of the url (i.e., Scripts/jquery-1.4.1.min.js?) some browsers (Firefox at least) will change to check for a new version of the file every time like it will for images. This could be useful during development.
Some developers will also append a version to the file (?123) so that they can cause the browser to ignore the cache completely when a new version of a web app is released. I'm not sure how effective this is if you already have a question mark at the end, since it will be looking for an updated version anyway (again, not sure about all browsers).