DEV Community: amt8u

Understanding Javascript hoisting

amt8u — Mon, 28 Sep 2020 12:19:52 +0000

Can you guess the output of the below program?

console.log(hoisting);
var hoisting = "Its a variable"
console.log(hoisting);
function hoisting(){
    return "Its a function";
}
console.log(hoisting);
var hoisting = "What is it?"
console.log(hoisting);

To know the actual answer you can go to the bottom of the post. If you cannot digest the answer, this post is for you.

To start with, hoisting is defined by the dictionary as Hoisting to raise or lift, especially by some mechanical appliance which basically means to move up.

Hoisting is JavaScript's default behavior of moving declarations to the top.

w3schools.com

Why do you need to move?

Lets start with simplest example. Fire up your devtools and type in the below line.

// Uncaught ReferenceError: someRandomName is not defined
console.log(someRandomName);

In the above case you will get an error while in the below example you will get undefined as return value.

// undefined
console.log(someRandomName);
var someRandomName;

For somebody who is starting to learn JS, this is just totally illogical. At first glance you will say "ah.. declarations are given priority". Great. But then if you run the below example, your start losing trust.

// undefined
console.log(someRandomName);
var someRandomName = "Are you trying to find logic here?";

Whats wrong?

Before I explain what hoisting is, you need to unlearn the definition that you have been fed from various sources - Hoisting is not moving the variable declarations to the top. Though once you understand the concept, you would probably agree to the definition. But the problem is when you haven't yet understood, the definition brings more confusion rather than clarity.

Is Javascript interpreted languange?

Its debatable but the simple answer is - its NOT. Javascript is also not a typical compiled language. It lies somewhere in between.

What is it then?

When you supply the script to the js engine, which in most cases would be a browser, it would first parse your script. It will read your script line by line and find out all the declarations made in the scope. Remember it only looks for declarations in the current scope. So by default when it loads the script, it only looks in the global scope.

What all it looks for?

The parser would look for all var and function declarations. With ES6, it will also look for const and let. But its mostly the same approach except one edge case which we shall cover in a minute. A simple statement like var x=6 has two parts -

declaration - var x
statement - x=6

Only the declarations are read, assignments are NOT. Assignments are just statements which will be run only in the second stage.

Once all the declarations are identified, the parser keeps a note in memory and asks the engine to start executing the same script line by line. So basically the same code is read twice. Though it will not be technically correct, we can say the first pass is compilation and the second pass is execution of the same code. In traditional compiled languages, compiled version of the original code is executed.

Thats why it doesn't matter where you declare the variable or function. If there is any var anywhere, it will be registered as declared without a value which by default is represented by undefined. But if its a function, the function definition also becomes a part of declaration and is stored at the same time.

console.log(x)
var x="Move it";
console.log(x);

Above code can also be represented as below snippet. Many tutorials/articles say that above code gets translated into the below code. That does not happen. This is just an illustration. The parser does not alter/modify your code. Its just how the code is read two times which makes you feel as if the declarations moved from their original location in the code to the top of the function.

var x;
console.log(x);
x = "Move it";
console.log(x);

Got it?

Now that you understand how a script is read and parsed, its time for another confusion

console.log(foo);
function foo(){
    return "This is a function.";
}
var foo = "Are you kidding!"
console.log(foo);

As per our understanding till now, the above code should output as below

undefined
Are you kidding!

Instead you will get the below output

ƒ foo(){
    return "This is a function.";
}
Are you kidding!

In the first parse, the engine will identify that there is a foo function declaration, so it assigns an identifier and also associates a function definition to it. Remember function declarations are read differently than assignments as mentioned earlier.

On encountering the second declaration for the same keyword foo, the engine should override the previously identified function right? But that doesn't happen. Function declarations are always given priority over var declarations. It doesn't matter how many times you write var, after the first parse, only function declaration will be kept.

var bar =  56;
var bar = 99;
function bar(){ return "Function is high priority";}
var bar = "Assign some string";

But what about this case? Multiple function declarations with same name. This time your intuition is right. The last one is taken into account.

foo()
function foo(){console.log("First one");}
foo()
function foo(){console.log("Again!");}
foo()
function foo(){console.log("Not again!");}
foo()

Not again!
Not again!
Not again!
Not again!

Is there any other catch?

let there be. When you ask what is the difference between let and var, a common accepted answer is - let/const declarations are not hoisted. Consider the below example. If we go by the accepted answer, let declaration will be ignored in the first parse. In the execution phase, line#1 should create a global variable and assign a string "Gotcha!" to it. And then of course, it would print that value and on line#3 there will be a new local block scoped variable created and assigned a value "Bad karma!".

foo = "Gotcha!";
console.log(foo);
let foo = "Bad karma!";
console.log(foo);

But if you run the code in a fresh window, you will see that it gives an error. A special kind of error.

Uncaught ReferenceError: Cannot access 'foo' before initialization

It turns out that `let/const` declarations are also hoisted but assigning values to them is restricted until the line where the declaration is made, gets executed.

The above phoenomenon is called as Temporal Dead Zone. And is only applicable to let/const block scoped variables.

But why god why?

Now that we know what hoisting is, we shall also dig into - Why its there?

Whats the purpose of having such a confusing feature?
Whats the point in executing the script like this?
Executing line by line would have been much easier?

This is just my perception and I might be wrong here but after reading about JS from multiple sources, I guess it all boils down to the fact that -

Javascript was for content writers. NOT programmers.

When Brendon was asked to come up with a scripting language, the whole idea was to give some control to the HTML creators so that they can create simple actions on the client side. You must have seen code like this on legacy products

<button onClick="showUserData()" name="getdata">Show User Details</button>

function showUserData() {
    // update the DOM to show user data on screen.
}

The function showUserData just toggles some div on the UI. This function can be called from many places, and not just the click event. Some other event can also trigger this function. To make it simple for the creators where they should not worry about defining the variables and functions before using them, Brendon might have come up with this approach.

This method would have made sense at that time when scripts were like 100-200 lines. Only a small set of functions to manage which can be used anywhere in the script as well as html easily.

But slowly JS started to grow because of the endless possibilities and the rich interactions it provided which HTML was unable to offer. We started writing scripts with 1000 lines of code and of course imposing practices from other languages which do not fit with the JS design, we have the end result where every thing which was a feature at some point of time is now considered a bad design.

Nevertheless, if you understand the base concept, it becomes easy to program and helps in understanding other's code as well.

Add PWA support to ghost theme

amt8u — Tue, 15 Sep 2020 14:42:28 +0000

What is PWA?

Progressive Web Apps are web apps that use emerging web browser APIs and features along with traditional progressive enhancement strategy to bring a native app-like user experience to cross-platform web applications. - Wikipedia

As always, the definition does not serve any purpose in explaining the feature. You need to learn it to understand it.

In simple terms PWA is a set of techniques to make your website behave like an app. To achieve this, you need to use a combination of features provided by the browser and the underlying operating system.

A detailed introduction can be found on mozilla.

Getting started

Ghost CMS is specifically targetted towards blogging. Learn more about it here

Since I didn't want to reinvent the wheel, I just copied the code from the below post which I referred to add PWA support on this site. Do check it out for more info.

BironThemes

To start with, we shall add offline support with a service worker to a ghost installation.

Unlike wordpress Ghost has integrated SEO with a pretty fast nodejs based templating engine. But it does not provide PWA support out of the box. Maybe in future it might come. But for now you have to do it manually.

There are 4 things that you need to do to convert your ghost blog into a PWA

Convert your site into https:// if not done yet
Add a manifest file which describes various attributes for your app
Add a service worker to your site which handles caching
Enjoy

Add manifest file

Create a new file in the root of your theme. You can give any name. Most of the options are self-explanatory. Important ones are name and icons. The color will be used as background splash screen while your app opens.

The display property handles how the app should be rendered. It has four options - fullscreen, standalone, minimal-ui and browser.

{
    "name":"Cybercafe.dev",
    "short_name":"Cybercafe",
    "description":"A blog by z00md",
    "lang":"en",
    "start_url":"/",
    "background_color":"#ffffff",
    "display":"fullscreen",
    "theme_color":"#313b3f",
    "icons":[
       {
        "src": "/assets/icons/z00md_logo.png",
        "type": "image/png",
        "sizes": "200x200"
      }
    ]
}

More details about properties can be found here

Add service worker

Manifest only provides basic settings for your app. To gain full control of the behavior, you need to manually add a service worker whose task is to determine what to do in case there is no network.

To make your site installable as an app you need to have a service worker with a fetch handler.

More details available on web.dev

const PRECACHE = 'precache';
const RUNTIME = 'runtime';

// A list of local resources we always want to be cached.
const PRECACHE_URLS = [
  '/',
  '/offline/'
];

const OFFLINE_URL = [
  '/offline/'
]

// The install handler takes care of pre caching the resources we always need.
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(PRECACHE)
      .then(cache => cache.addAll(PRECACHE_URLS))
      .then(self.skipWaiting())
  );
});

// The activate handler takes care of cleaning up old caches.
self.addEventListener('activate', event => {
  const currentCaches = [PRECACHE, RUNTIME];
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return cacheNames.filter(cacheName => !currentCaches.includes(cacheName));
    }).then(cachesToDelete => {
      return Promise.all(cachesToDelete.map(cacheToDelete => {
        return caches.delete(cacheToDelete);
      }));
    }).then(() => self.clients.claim())
  );
});

// The fetch handler serves responses for same-origin resources from a cache.
// If no response is found, it populates the runtime cache with the response
// from the network before returning it to the page.
self.addEventListener('fetch', event => {
  // Skip cross-origin requests, like those for Google Analytics.
  if (event.request.url.startsWith(self.location.origin)) {
    event.respondWith(
      caches.match(event.request).then(cachedResponse => {
        if (cachedResponse) {
          return cachedResponse;
        }

        return caches.open(RUNTIME).then(cache => {
          return fetch(event.request).then(response => {
            // Put a copy of the response in the runtime cache.
            return cache.put(event.request, response.clone()).then(() => {
              return response;
            });
          }).catch(error => {
            // Check if the user is offline first and is trying to navigate to a web page
            return caches.match(OFFLINE_URL);
          });;
        });
      })
    );
  }
});

Update `default.hbs`

Now that we have the sw.js and manifest.webmanifest handy, we need to tell the browser where to look for this. As we do with other resources like css we need to create a link tag with href to our manifest file. Note that I have shown the <head> section only below. Your default.hbs would have a lot of other code too.

<head>

    {{!-- Document Settings --}}
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />

    {{!-- Base Meta --}}
    <title>{{meta_title}}</title>
    <meta name="HandheldFriendly" content="True" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    {{!-- Styles'n'Scripts --}}
    <link rel="stylesheet" type="text/css" href="{{asset "built/screen.css"}}" />

    {{!-- This tag outputs SEO meta+structured data and other important settings --}}
    {{ghost_head}}

    {{!-- PWA --}}
    <link rel="manifest" href="/manifest.webmanifest">
    <meta name="theme-color" content="#313b3f">
    <link rel="apple-touch-icon" href="/assets/icons/z00md_logo.png">

</head>

We also need to tell the browser to register our service worker and start executing it. For this we can use browser's navigator api.

Just goto the end of your body tag and add the below script. navigator is a browser api that gives a lot of information about the device, geolocation, cache, storage etc. We will use its serviceWorker object to register our sw.js file.

    {{!-- Service Worker for PWA --}}
    <script>
    if ('serviceWorker' in navigator) {
        window.addEventListener('load', () => {
        navigator.serviceWorker.register('/sw.js');
        });
    }
    </script>

Create offline page

You need to create a page which will be shown whenever your app is unable to connect to your site. For this you can create a new page under ghost admin. You can edit the page as you like but just keep the url of the page same as what you have given in the service worker.

const OFFLINE_URL = [
  '/offline/'
]

Run it!

Now that everything is setup. Its time to build and run your app. Depending on the build theme and the build tool used by it, you might need to configure package.json. For me it worked by default.

If you have a local ghost dev environment running and you have configured it to use local dev theme, you could just run below command and refresh the browser cache.

yarn dev

You can always build your theme and then upload the built version on your local ghost instance or production instance.

yarn zip

If everything runs fine, you should see a new action when you open your site on mobile browser - Add to home screen. You will be able to install your site as a native app on your device. And as you open various pages, they start getting cached. Try switching data/wifi off and load your app. You should still be able to navigate to the pages you visited. And for the rest of the URLs you should see the offline page which you created from ghost admin.

Things to note - My observations : may be wrong

localhost is http

Service workers will only work on https:// sites. And there is only once exception - localhost. If you are trying to test whether everything works locally, you need to use http://localhost:<port> URL. Other than localhost service workers don't work and manifest file is not downloaded. And of course you would also not get any errors. The tag containing the manifest is ignored completely.

Cache

Once the service worker is registered, it starts caching resources and will always serve from the service worker cache. Note that this is different from your browser based http cache. So even if you disable cache in dev tools, the files will continue to serve from service worker. You need to use the Bypass for Network option under the dev tools Application tab. You can also use the Offline option to simulate no network and test your app.

Refresh service worker

Did not like the name or background color you gave to your app in the manifest. You changed it, build your theme and disabled all caches but still your changes does not seem to work? I am not sure about the expiry strategy for service workers but as per my observation, it doesn't refresh on disabling cache. You need to unregister the service worker to get your changes to reflect.

What to do on mobile to refresh everything

Its really difficult to test on mobile devices since we don't have dev tools where we can just disable cache for that one particular tab. Also once you have installed the web app, its no longer a browser cache that needs to be cleared. For me I had to goto app manager on android and remove the data/cache from settings menu to get it to refresh. And of course you would need to clear your browser cache as well, otherwise your browser will just use its cached version and you will still not get your changes.

Few steps that helped me troubleshooting on mobile

Uninstall app
Clear storage and cache for your app on android under settings
Clear browser cache from browser settings for your site
Reload in browser
Again add your app to home screen via browser menu

More details about properties can be found here

End note

Progressive web apps is not just one property. Instead it is a set of techniques combined together to create a seamless user experience. Its still developing and will sure change in near future. Needless to say, not every platform supports every feature. Just be cautious about it.

Update on 13 Sep 2020

Because of the cache first strategy used in the service worker, I was having many issues

New articles won't appear

This is due to the fact that Homepage was served from cache always. To overcome this, I updated the service worker to use Network first strategy which means show cached files only when network call fails. And present an offline page if both fail.

This strategy has one disadvantage though - You need to wait for the network call to finish which loses the blazing fast caching feature. I guess, a cache first strategy will be more effective. Will try that out later.

Ghost admin going into 500 errors

This might be happening because all GET calls were being served from cache with inconsistent data.

I added a check in the service worker to ignore all admin calls

// The fetch handler serves responses for same-origin resources from a cache.
// If no response is found, it populates the runtime cache with the response
// from the network before returning it to the page.
self.addEventListener("fetch", (event) => {
    // Skip cross-origin requests, like those for Google Analytics.
    // Skip all ghost admin requests to prevent 500 errors
    if (
        event.request.url.startsWith(self.location.origin) &&
        !event.request.url.startsWith(`${self.location.origin}$/ghost}`)
    ) {
        event.respondWith(
            caches.match(event.request).then((cachedResponse) => {
                return caches.open(RUNTIME).then((cache) => {
                    return fetch(event.request)
                        .then((response) => {
                            // Put a copy of the response in the runtime cache.
                            return cache
                                .put(event.request, response.clone())
                                .then(() => {
                                    return response;
                                });
                        })
                        .catch((error) => {
                            // Return cached reponse if network fails
                            if (cachedResponse) {
                                return cachedResponse;
                            } else {
                                // Return offline page if network and cache both fail
                                return caches.match(OFFLINE_URL);
                            }
                        });
                });
            })
        );
    }
});

End

First published on my personal blog cybercafe.dev

DEV Community: amt8u

Understanding Javascript hoisting

Can you guess the output of the below program?

Why do you need to move?

Whats wrong?

Is Javascript interpreted languange?

What is it then?

What all it looks for?

Got it?

Is there any other catch?

It turns out that `let/const` declarations are also hoisted but assigning values to them is restricted until the line where the declaration is made, gets executed.

But why god why?

Javascript was for content writers. NOT programmers.

Further reading

Output of the code at the top of the article

Add PWA support to ghost theme

What is PWA?

Getting started

Add manifest file

Add service worker

Update `default.hbs`

Create offline page

Run it!

Things to note - My observations : may be wrong

localhost is http

Cache

Refresh service worker

What to do on mobile to refresh everything

Further reading

End note

Update on 13 Sep 2020

New articles won't appear

Ghost admin going into 500 errors

DEV Community: amt8u

Understanding Javascript hoisting

Can you guess the output of the below program?

Why do you need to move?

Whats wrong?

Is Javascript interpreted languange?

What is it then?

What all it looks for?

Got it?

Is there any other catch?

It turns out that let/const declarations are also hoisted but assigning values to them is restricted until the line where the declaration is made, gets executed.

But why god why?

Javascript was for content writers. NOT programmers.

Further reading

Output of the code at the top of the article

Add PWA support to ghost theme

What is PWA?

Getting started

Add manifest file

Add service worker

Update default.hbs

Create offline page

Run it!

Things to note - My observations : may be wrong

localhost is http

Cache

Refresh service worker

What to do on mobile to refresh everything

Further reading

End note

Update on 13 Sep 2020

New articles won't appear

Ghost admin going into 500 errors

It turns out that `let/const` declarations are also hoisted but assigning values to them is restricted until the line where the declaration is made, gets executed.

Update `default.hbs`