#javascript difference between const and var

OVERVIEW

Alright, so what are we even adding? Basically, Masonry is used to display your posts in a nicely laid out grid, even if they're all different sizes. You tell it what your posts are, what you want them to fit into and it'll come up with a nice grid layout for you. Infinite Scroll is used to... infinitely scroll through posts with having to go to another page. It’s the endless scrolling of your Twitter/Instagram/whatever feed.

Now maybe you’ve already got one or the other in your theme and you’re looking to add the other one. Sounds pretty simple, yeah? It kind of is. The trouble is that Masonry and Infinite Scroll interact with each other. When you’re using Infinite Scroll, whenever you scroll down and load more posts, Masonry needs to check whether your post layout is still okay and correct it if it isn't.

PLUGINS

For the sake of this guide not getting too confusing and because they integrate so easily together, we’ll ONLY be using David DeSandro's Masonry and Infinite Scroll Javascript plugins. If you’ve got different versions of these plugins, remove them now as they may cause issues.

First, we need to add the plugins to your theme’s head:

<script src="https://unpkg.com/masonry-layout@4/dist/masonry.pkgd.min.js"></script><script src="https://unpkg.com/infinite-scroll@4/dist/infinite-scroll.pkgd.min.js"></script>

HTML

To get Masonry working, we need to know what your posts are and the container that they're in. Give your posts a class (e.g. .post) and your container an id (e.g. #posts). We can also specify additional options, such as column width and spacing between the posts. We want the layout to be responsive, so by following the example code Masonry provides, we'll create post-sizer and gutter-sizer.

To add Infinite Scroll, we need to know what the posts are (same as Masonry) and where to get the new content from - this will be the next page of posts on your blog. Tumblr lets us get that easily using pagination variables. Make sure you give the next page a class (e.g. .pagination__next), since this is where we'll be loading new posts from.

Your HTML might look something like this:

<div id="posts"> <div id="post-sizer"></div> <div id="gutter-sizer"></div> {block:Posts} <div class="post" id="{PostID}"> <div class="post-content"> {block:Text} {/block:Text} </div> </div> {/block:Posts} </div> <p id="footer"> {block:PreviousPage} <a href="{PreviousPage}">« Previous</a> {/block:PreviousPage} {block:NextPage} <a href="{NextPage}" class="pagination__next">Next »</a> {/block:NextPage} <a href="/archive">Archive</a> </p>

CSS

For the styling, we want the layout to be responsive so we'll set post-sizer and gutter-sizer to have a % width. For the rest of the styling, we'll use some of Masonry's example code again.

Your CSS might look something like this:

* { box-sizing: border-box; } #posts { width: 800px; } #posts:after { content: ''; display: block; clear: both; } #post-sizer, .post { width: 32.66%; } #gutter-sizer { width: 1%; } .post { background-color: lightgrey; margin-bottom: 10px; } .post-content { width: 100%; padding: 10px; float: left; }

JAVASCRIPT

In your theme's head, we can create a new script and set up Masonry inside it like this:

<script> window.onload = function() { var elem = document.getElementById('posts'); var msnry = new Masonry(elem, { itemSelector: '.post', percentPosition: true, columnWidth: '#post-sizer', gutter: '#gutter-sizer' }); } </script>

Then to actually get Masonry to generate a layout, we need to call it like this:

msnry.layout();

Usually, that's all you really need for Masonry but for Tumblr posts, any media embeds might take a bit of time to load. For example, Instagram embeds get taller when they're fully loaded (or at least they used to) and this can screw up the layout of your posts. To deal with this, you can add an observer that checks for any changes with media embeds and calculates a new layout if needed:

const embedObserver = new MutationObserver((m, o) => { msnry.layout(); }); embedObserver.observe(document, { childList: true, subtree: true });

Then finally, we need to set up Infinite Scroll. Remember, we're using the same posts that Masonry is changing. Since this plugin is made by the same guy who wrote Masonry, we can integrate it easily using outlayer:

let infScroll = new InfiniteScroll(elem, { path: '.pagination__next', append: '.post', outlayer: msnry });

Every time it loads a new page, it'll update the URL in your address bar. If you want to turn that off, you can add a new line to the previous codeblock, setting history to false:

let infScroll = new InfiniteScroll(elem, { path: '.pagination__next', append: '.post', history: false, outlayer: msnry });

And that should be it! The whole script should be something like this:

<script> window.onload = function() { // INITIALISE MASONRY var elem = document.getElementById('posts'); var msnry = new Masonry(elem, { itemSelector: '.post', percentPosition: true, columnWidth: '#post-sizer', gutter: '#gutter-sizer' }); // CALL MASONRY LAYOUT msnry.layout(); // CALL MASONRY LAYOUT ON EMBED LOAD const embedObserver = new MutationObserver((m, o) => { msnry.layout(); }); embedObserver.observe(document, { childList: true, subtree: true }); // INITIALISE INFINITE SCROLL let infScroll = new InfiniteScroll(elem, { path: '.pagination__next', append: '.post', history: false, outlayer: msnry }); } </script>

FINALLY...

Do keep in mind that your theme code will be different to this, so it's not a case of just copying and pasting everything directly. Remember to remove any old Masonry or Infinite Scroll plugins you already have. Your class and id names will probably be different and you may need to add certain HTML elements if you're missing them. You'll almost certainly need to tweak the styling too.

Var and let seem very similar at first glance, but they are not truly synonymous. One big difference between the two is that of scope. The var keyword defines a variable globally or locally to an entire function regardless of block scope. By contrast, let allows you to declare variables that are limited in scope to the block, statement, or expression on which it is used. 

To further expand on this, variables declared with var are either function-wide or global and cannot be block-local or loop-local. Var ignores code blocks and so pierces through them. Because var can declare variables globally or inside a function, when the variable’s value is reassigned inside a block later, the original value of var updates. See below for an example:

function() {    var x = 1;    console.log(x) // 1    if(true) {        var x = 2        console.log(x) //2    }    console.log(x) //2 }

On the other hand, since let limits the value of a variable within a block scope, the original value will be left unchanged as illustrated below:

function() {    let x = 1;    console.log(x) // 1    if(true) {        let x = 2        console.log(x) //2    }    console.log(x) // 1 }

Var declarations are also processed at the beginning of a function (or script for globals) unless the definition is in a nested function. This is called hoisting because all var are hoisted or raised to the top of the function. Even if an “if” branch never executes, the var inside it is processed in the beginning of the function. Although these declarations are processed at the start of function execution, assignments are not hoisted and work at the exact place they appear. This means that although all var declarations can be referenced at any place since they are processed at function start, they are undefined until assignment. 

Variables declared with let are not subject to variable hoisting which means they cannot be referenced before the block where initialization of that variable occurs (without receiving a ReferenceError). The variable is in what we call a temporal dead zone from the start of the block until the initialization is processed. Let variables may be reassigned (such as with a counter within a loop), but you can only declare a let variable inside of its scope once. The latter is not true for var which can cause bugs.

Let me say this one more time because it was confusing to me initially: you can update a let variable, but you cannot redeclare it twice in the same scope.

Const is similar to let in that it is block-scoped. With const, the value cannot be reassigned. Unlike var and let, the use of const also requires an initializer which means it cannot be used to declare an empty variable. 

Take a look at this:

const name = 'Player1'; let points = 50; let winner = false; if(points > 40) {   let winner = true }

Although it looks like there is only one winner variable here, there are actually two separate winner variables because they are scoped differently, even though they have the same name. The first winner is scoped to the window but the second one is scoped to the block because it is within the “if” loop. Logging the let variable at the end of this code would return winner as false, but changing let to var would return winner as true because the variable would not be scoped to block, meaning that the original global variable would undergo reassignment because of what’s inside the “if” loop.

The difference between let and const is that const makes a contract that no rebinding will happen. This means you cannot alter a const value by using an assignment operator or a unary or postfix operator (--, ++, etc) without encountering a TypeError exception. The value of const freezes the moment it is declared and cannot be reassigned.

This can also be a bit confusing though, because it is possible to change the properties of a const variable. The object itself is not immutable, but the binding is. 

Wes Bos describes const well when he says that you can think of a const object as a person. A person’s entire identity will never change; it will remain essentially the same. Although your personality could waver, you will still always be you (unless you’re Taylor Swift I guess). Your value cannot be reassigned. However, your properties can be. Your hair color, your job, your sleep schedule, your age, etc. -- those are all subject to change. Your identity isn’t. You can change properties as long as the object base remains the same. That can be illustrated with the following code:

const person = {  name: 'Noey',  age: 22 } person.age = 23

There’s no problem with this, but the entire variable value cannot be changed.