Memory Calculator

Link to the project

This is a completely front-end project made with vanilla ES5 Javascript, HTML and CSS. It uses Local Storage to store the equations saved for the next browsing session (as long as the source URL and protocol is the same).

UI wise I have included a blinker animation for the calculator display and invalid animations for when a button click is not allowed (in addition to the usual tactile transitions or animations). An example of an invalid button click would be when trying to add two decimal places to the same number. The invalid animation will be trigger for this action. Also, when an operation button is clicked when there is already an operator at the end of the display, the operator sign will simply change. This comes from the principle of design to reduce errors upfront. Rather than letting the user press two operator buttons in a row and get a syntax error, it is designed in a way that only one operator is allowed between every number in the equation. This is for example why ATMs often give cards out first then cash, to reduce the chances of people leaving their cards at the ATM. The design of the app is also such that there is an implied clear line from the bottom of the app—in between the operation keys and number keys—and the top of the app—between the div for Equations Saved and View Saved Equations. This is because human beings are good at adding implied lines to any design and makes for a cleaner look.

Note: This calculator does not follow BODMAS which is the rule for division and multiplication before addition and subtraction. This is within the design of the app and is not a bug. I originally intended for the operations.js to behave the way it does so that a user could press C to return from a syntax error without losing what has already been input into the equation. This was implemented due to the frustration I have faced on some websites where upon submitting the form it would return empty and signal an error in input.

Bug Fixes

Just a lits of bug fixes since I initially uploaded the project on Github. Gives me a change to get more familiar with git as well.

• Fixed an answer-line bug where the value of the answer on the display's answer-line and cover's ul element does not tally with the value of answer stored internally in operations.savedAnswer.

Reflecting on my growth since my first GitHub project

My first project on GitHub was a to-do list. I had a limited knowledge of how Javascript worked then and I often got jQuery and Javascript mixed up. I had followed a lengthy tutorial (Coffeerun) from a book called WebNerdRanch and I reversed engineered it a couple of times. I then modified it heavily by adding a slider, tables for uncompleted tasks, a timer for each task, a completed tasks list and much more to turn it into a to-do list. Since then I have studied Javascript and CSS heavily and decided to build this project without using any frameworks such as Bootstrap or jQuery. I now understand the tools much better and to prove it I have included a What’s Going On section in this Readme. I have also read a couple of blog posts and articles on UI design and have thus included the features described in the Memory Calculator description above. For my future project I envisage that it will involve a backend using Node.js, I will make use of ES6 Javascript features such as Promises and that it will involve a larger amount of asynchronous operation.

What’s going on

I intend this to be an explanation of Javascript and how it specifically relates to the code in my project. It is in no way meant to be an exhaustive explanation of the Javascript concepts presented. It is just so I can prove that I understand what is going on in my project.

a) How the DOM is built

The DOM is the browser’s internal interpretation of the HTML document. The browser builds the DOM by going from one HTML tag to the next. When the browser sees a script tag, it executes the Javascript in the entirety of the script. Only when it gets to the end of the script does it move onto the next HTML tag. Consider the below code taken from index.html:

    <script src="scripts/operations.js" charset="utf-8"></script>
    <script src="scripts/display.js" charset="utf-8"></script>
    <script src="scripts/buttons.js" charset="utf-8"></script>

What is vital for my project is that when the global window object is modified by the execution of operations.js and the browser moves on to the next HTML script tag—which in this case starts the execution of the code in display.js from start to finish, before moving on to the next HTML tag— the modification to the global object is cumulative.

b)IFFE modules

Since this project was intended to use only ES5 Javascript, to modularise my code I have implemented the IFFE pattern. ES5 does not have block scopes, only function scopes and the global scope. The IFFE is useful for not polluting the global namespace and only exposing the constructor functions and the methods attached to their prototypes to the global window object while keeping its implementation details hidden. As in this code below taken from the display.js file shows:

(function(window){
var App = window.App || {};

///(…modified for brevity….)

App.Display = Display;
window.App = App;
})(window);

In the snippet above I attach the Display constructor function as a property of the App object defined in the global namespace. The App object is the returned module object that gets extended when passed into the other IFFEs in the other Javascript files. I have attached the constructor functions to the App object so as to not clutter the global namespace with identifiers.

One of the main problem with the IFFE module pattern is that we as developers have to manage the dependencies as each module may be dependent on another module for its execution. To handle this I have the main.js file. It handles the main logic which ties all the modules together and it the last script tag. So, it will be run only after all the submodules that extend the App module object are loaded. Within each submodule as well the first line of the IFFE (for example var App = window.App || {}; in the above) at the start of the IFFE is just so I do not have to have to be pedantic about the order of each submodule's script tag in the HTML document. I would only have to ensure that the main.js script tag is the last.

Note: Declaring variables in the global namespace is the same as attaching a property to the global window object.

c)The use of “use strict”

Puns aside the use strict keyword in my project is beneficial to ensure that there are no leaked global variable declarations. The code below is modified from main.js and has a variable declaration removed on purpose. For illustration purposes I have also named the anonymous function in the IFFE:

( function MainAnonymous(window) {

//var has been removed!
  NUMBER_BUTTON_SELECTOR = '[data-button = "number"]';
  var OPERATION_BUTTON_SELECTOR = '[data-button = "operation"]';
  var C_BUTTON_SELECTOR = '[data-button="cancel"]';

///(…modified for brevity…)

})(window);

When the JS engine encounters the IFFE it immediately runs the function MainAnonymous and puts a new function context on the call stack. A new function scope is also created for the MainAnonymous function. The MainAnonymous function also gets a hidden [[Environment]] property that references the scope in which it was created which in this case is the global scope.

Before any of the code in the function MainAnonymous is run, an identifier is first made and linked to the window parameter of the MainAnonymous function. Then the code is scanned for any function declarations. If any function declarations are found the functions are created with their own [[Environment]] property pointing to the scope of the IFFE and their identifiers are assigned to the function value. Then the code is scanned for any variable declarations not contained within functions. If an identifier to the variable declaration has not been registered in the scanning for functions step, the identifier is created and initialized to undefined. Only then is the code run line by line. This is often visualised as hoisting.

When the engine gets to the line NUMBER_BUTTON_SELECTOR = '[data-button = "number"]'; it first searches the scope of the IFFE for an identifier to NUMBER_BUTTON_SELECTOR but since the variable was not declared and thus initialized to undefined as per the previous discussion, the engine looks into the parent scope of the IFFE –the global scope—via the hidden [[Environment]] property of the function MainAnonymous for the identifier. When it gets to the global scope and cannot find a identifier to NUMBER_BUTTON_SELECTOR, a variable in the global scope is declared. This only occurs in the case of the modified code above since the use strict keyword was not included. If the use strict keyword was included however, it would throw a Reference Error as it would not allow leaked global variable declarations.

d)My use of the prototype object and this and the new keyword

Every function gets a prototype object that is a property attached to said function. If object1 is a prototype of object2 and we search for a property on object2 that object2 does not have on itself. It will delegate the search for that property to its prototype, object1. In turn object1 can have a its own prototype forming a prototype chain. To explain this and the new keyword I would like to refer to some of my code written below.

From operator.js:

(function (window) {
'use strict';
var App = window.App || {};

//(...yet again liberally modified for brevity...)

function Display(equationLineSelector, answerLineSelector) {
      this.equation = document.querySelector(equationLineSelector);
      this.answer = document.querySelector(answerLineSelector);
      this.saved = false;
      this.decimalAble = true;
      this.error = false;
    }

Display.prototype.setAnswerLine = function (number) {
      //incase of Infinity
      if(!isNaN(number) && !isFinite(number)){
          this.showNumberError()
      }
      //in case of NaN
      else if(isNaN(number)){
          this.showSyntaxError()
      }
      else{
        this.error = false;
        this.answer.textContent = number;
      }
    };

    App.Display = Display;
    window.App = App;

})(window);

And the related snippets in main.js:

  var display = new Display(DISPLAY_EQUATION_SELECTOR, DISPLAY_ANSWER_SELECTOR);

  buttonControl.addNumberHandler(function(text) {
    if(operations.getNumberOfOperations() === -1){
      display.appendNumberToEquation(text);
    }
    else{
      display.appendNumberToEquation(text);
      var number = display.getNumberAtEnd();
      var newAnswer = operations.updateAnswer(number);
      display.setAnswerLine(newAnswer);
    }
  });

The this parameter is what’s called often referred to as the function context. To find out what the this parameter is we have to ask: How is the function invoked? Consider the code above taken from both main.js and operator.js.

When var display = new Display(DISPLAY_EQUATION_SELECTOR, DISPLAY_ANSWER_SELECTOR); in main.js is run--display is run as a constructor function via the new keyword-- a new empty object is created. This empty object will be passed to the Display function as the value of this. It will thus go through Display and get the properties equation, answer, saved, decimalAble and error. It will also get its prototype set as the prototype object of the Display constructor function (Display.prototype). This object will be returned by the constructor function (Indeed it will be returned even if there was a return statement returning a non-object in the constructor function) and gets set as the variab