A calculator web application built from vanilla JavaScript as part of Founder's and Coders pre-course requirements.
To be submitted for review for Wednesday 26th February 2020.
The design criteria can be found here.
- currentOperand: The number in the main display which can be manipulated by user or is the result of a calculation
- operation: JavaScript Arithmetic Operators
- previousOperand: The previously defined number in the secondary display which will be used with the currentOperand and operation when evaluating the expression.
This calculator utilizes immediate execution logic and an Object Oriented Programming (OOP) approach.
I choose this appoach as I was interested in learning more about the class syntax and constructor functions. More specifically how they could be used as a blueprint for creating objects.
Note there are two JS files. They are identical except for a small difference in syntax:
- app-class.js (default: for review): This file uses a class function. The comments remain in the code to walk the reviewer though my thought process as I was building the application. Note there is a small issue with functionality (see Point 6 in Improvements).
- app.constructor.js: Refactored code without the class syntax using constructors and prototypes. Created to illustrate differences in syntax with classes. Better functionality than above calculator because of Point 6. View this calculator here.
- Build A Calculator With JavaScript Tutorial
- JavaScript Classes Tutorial: to manipulate DOM to show calculation history.
- Object Oriented Programming Challenges from FreeCodeCamp
- Buttons must have discernible text: for guidance on describing button functionality for screen readers.
- How Button Input Type Creates A Form Button In JavaScript: For decision on using or .
- The application should take a mobile first approach and be responsive for smaller screens. However, most smaller devices have calculator mobile applications so the typical user would be using a computer.
- After reading this article I decided to use input elements instead of buttons. As some of the input values were not intuitive I used both value and aria-label attributes.
- Data types are used to interact with JS and IDs for CSS to seperate out styling and script based behaviour. Although if the data type or ID changes at a later date the author would have to update both the style and JS sheets. Q: Is this unnecesary or good practice?
- Semantics: Input elements with type='button' chosen over button elements. Used a element because the calculator contained interactive controls for submitting information. Used a Aria role='application' to indicate to assistive technologies that it is a desktop application.
- Using a value attribute or innerText to describe button function: I wanted the equivalent of alt text for images to describe unintuitive button functions such as DEL, AC and MR. I was going to delete the buttons' value attribute as it seemed like surplus code. However, as this guidance suggested using either an aria-label or value attribute I decided to proceed using aria labels.
- A discernible difference is needed between active and focused buttons to show they have been selected by user.
- The user experience for keyboard users. Tabbing through the input elements is rather monotonous. Use of number and arrow keys would improve usability.
- Calulation history could be saved locally using localStorage.setItem and getItem.
- The operation sign cannot be changed after it is selected.
- Declare eventListeners for number key presses so user can use keyboard to input numbers.
- Facilitate use of arrow keys.
- After a calculation is executed, if equals is pressed again the execute same equation but replace currentOperand with new value.
- app-class.js script sheet: If pressing an operation button to evaluate the expression, it must be pressed again to be applied to the newly calculated value.
- If user clicks on an equation in the calculation history list, the currentOperand displays the calculated value.
- Styling is functional but not eye catching.
- Use of MR button not intuitive. Could add a key to describe function of each button.
- ID limitations: An ID will override a class in CSS. So if a class is added to an element using JS and it clashes with ID styles the ID will always win.
- Relationship between IDs, classes and data atttributes with JS: Following Point 1, there needs to be a clear strategy for how the programmer is going to interact with HTML elements using CSS and JS. Q: What is best practice?
- Input limitations: Pseudo classes cannot be used with input elements and they cannot contain text. A button element was used for MR (Memory Recall) so I could use pseudo class to add an icon.
At SHA 07051e0 I encountered a problem with version control. I created a new branch gh-pages to publish my site. As the new branch did not show in the remote version I tried to push it to the remote and received this error fatal:
The current branch gh-pages has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin gh-pages.
After using this command I tried to revert to a previous commit so I could get back to the starting point. However, I could not push this because the remote was ahead.
In the end I just pulled from the remote and started again from 07051e0 and merged with the local in SHA a9eaaef and lost some small updates.
My project page was not publishing. I read on Stack that a Jekyll theme was required for pages to show. In selecting one on GitHub it (unknowingly to me) created a new commit just on the remote. This commit was different to what I had in my local so when I went to push my local changes I received this hint:
hint: Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. 'git pull ...') before pushing again. See the 'Note about fast-forwards' in 'git push --help' for details.
The problem was that the local was ahead of the remote but because of the theme related commit Git thinks the remote is ahead of the local. I wanted the remote on GitHub to mirror the local but I didn't want to git pull in case I erase all the additional work.