Building a jQuery ATM

…since jQuery is all about the money $$$$$

The re-introduction of jQuery into my programming skill set was like a fat, ol’ payday check, right before the weekend.

You know how good that feels.

Fittingly, one assignment this week was to create programs for a “bank account” that would allow users to:
// deposit money into one of the bank accounts
// withdraw money from one of the bank accounts
// not withdraw more money than the account balance
// have overdraft protection — i.e., if the withdrawal amount from checking would go negative, take the remaining amount from savings

The HTML & CSS files were given to us, and our task was to write the JavaScript that would manipulate the DOM and do the simple math. To begin, I took each of the user stories and pseudo-coded the logic for deposits and withdrawals, focusing on one account at a time. I decided that the deposit function needed to grab the value from the input bar (entered by a user), add it to the existing value in the account, then display the sum. The withdrawal function became a bit more complicated, as it needed not only to get the value of the withdrawal and subtract it, but also to determine whether or not this value would overdraft the account.

Here’s my solution:

My first step was to set up event listeners on each of the buttons. There are two buttons for each account, which could have meant writing four functions — however, I knew that the buttons really needed to perform the same actions, just for different accounts (i.e. just manipulating different elements on the page). That means two functions. (Note: I did not use OOP, which I realize could mean one function overall. Alas.)

First, I tackled the deposit function, since this program has to execute fewer tasks in order to complete itself. In other words, this function was an easy (well, “easier”) win.

To write it, I assigned the value of the account to a variable, prevBalance. However, this value was stored as a string. Knowing that I’d need to perform simple addition with it later, I removed the ‘$’ from the value — replacing it with an empty string — then used parseInt( ) to change the data type to a number. Then I repeated the process for the second variable, newEntry.

In this context, “this” refers to the button that was clicked, which triggered the function. Looking at the code now — after the rush of writing it — I realize that I probably should have put classes on my input bar (rather than calling it by .siblings(“div.balance”) ). Oh well. That’s something for refactoring!

After that, I used .text( ) to modify the account balance. The .text( ) method will set the value inside an HTML element — and I already had the exact element to modify stored as prevBalance. I learned that you can call a function within the .text( ) method as well, so I used an anonymous function to total up the newEntry and the prevBalance values. Then I added the “$” back in, along with the new account total, and popped it into the account window.

So then it got tricky, and I wrote an ugly, nested function to contain all of the withdrawal functionality.

The first function shown here totals the value of the amount in both accounts. That comes into play as soon as the subtractMoney function is invoked, i.e. whenever there is a click on the “Withdraw” button for either account.

The withdrawal function mimics the deposit one, grabbing the values of the input box & account whose sibling button triggered the event, parseInt-ing them, then storing the values as numbers. Easy enough.

BUT THEN THIS:

This entire if-else statement runs inside of the subtractMoney function, proving that writing modular code is not yet my strong suit. There are three levels to the if-else if-else statement:

  1. If the click triggering the event is on the Savings account, either return the new total (prevBalance - newWithdrawal), or do nothing if the attempted withdrawal would take the account into a negative balance.
  2. Otherwise, check to see if the attempted balance withdrawal is greater than the total amount in both accounts. If so, inform the user that he or she is too poor to be spending that much money.
  3. Finally, if the click triggering the event is on the Checking account, do one of two things:

— If the account won’t go into a negative balance, let the user withdraw the money and display the new total.

— If the attempted withdrawal is greater than the account balance, as the user if he or she wants to proceed with the transaction. I figured that was a nice bank-ly thing to do. If the user confirms to proceed, the function subtracts the checking balance to 0, then subtracts a corresponding amount from the savings account.

The subtraction from the savings account stumped me, because I couldn’t figure out how to subtract the leftover amount. Then, an ‘aha’ moment: I already had that value stored as my variable, total. Because total was negative, I could simply add it to the savings account balance — a throwback to elementary school math class, in which you learn that adding a negative number === subtraction. (First-grade mind? Blown.)

That entire logic structure is nested inside the withdrawal function, which isn’t the most elegant solution. Oftentimes, good code is modular, kind of like an apartment building: The tenants (functions) have separate apartments and do different things, but they all live in one building (script file); here, I basically built a house inside of an apartment.

Yet, the ATM machine works as an MVP. While I wish I could have written a perfect program on the first shot, I don’t mind knowing that there are places in my code where I can go back and refactor it, improving it and offering myself a new challenge.