Like I explained in my introduction, Building from Scratch, a challenge usually has more than meets the eye, and I think part of what makes a tech consultant, product manager, solution architect, etc. good at their job is understanding the depth of a challenge and translating that into a tangible solution.
While I had grand ambitions of more complicated products, I ended up landing on the challenge of developing a savings calculator. It's not revolutionary, and definitely not something that hasn't been done before, but it's a good opportunity to build a simple tool with a socially conscious benefit, regardless of how basic. There are companies built entirely on the idea of providing calculators such as this one. SmartAsset comes to mind, or Wealthfront and their "Path" financial planning solution.
Back to the problem at hand, how do I build a savings calculator? The end result is relatively straight forward: a user-configurable calculator that leverages a combination of assumptions and calculations to project savings amounts over time, presumably to estimate wealth pre and post retirement. Ideally the whole calculation can happen live with near-instant recalculation both in the underlying data and an accompanying chart.
To accomplish this, I'll intend to follow this rough outline:
- Have a web application perform a simple compounding calculation.
- Allow user-inputs (variables) to dynamically update underlying calculations.
- Include a time-series line chart, tracking the value over a period of time.
- Live-update the chart with new data as it becomes available.
- Increase the complexity of the formulas driving the data calculation.
- Make it user friendly (UI/ UX), and refactor for efficiency.
This is exceptionally broad, but one of the more straightforward challenges. At the core of any programming idea is the concept of logic and variables. Build a formula, plug in values, and display the output. In the context of a time-varied element, there's more than one "output". Each year ends up being an output, but the base calculation doesn't change between each year. As opposed to Excel where you'd write the formula for each cell, this is likely accomplished with loops, storing the values in an array that can be fetched later. The most straightforward approach to accomplish this is to use Javascript.
With my limited knowledge of JS, I can already forecast the difficulty of making the calculation dynamic based on user inputs. Luckily, my exposure to a few Javascript frameworks, namely VueJS tell me that utilizing one can lift this burden immediately. In the case of VueJS, Declarative Rendering is one of the first things the docs page explains. In my elementary understanding, this will allow me to dynamically link my user inputs to the underlying calculations to make them immediately reactive.
I always used to wonder how sites like the NY Times used to come up with such complex graphs in their online articles. Luckily some digging years ago, and there's a range of fantastic Javascript libraries that help with charting. I've played with D3.js (which is used by the NYT in many of their dynamic data visualizations), but it has a steep learning curve for something simple in our case. I have experience using Chart.js, a fantastic library for simple, yet powerful charts that provides out of the box support for things like animations, tooltips, scaling (think mobile vs desktop), and styling. The plan is to use vue-chartjs as a Vue.js wrapper for Chart.js. Perhaps it's a tad overkill in my implementation, but if anything, the use of this will contribute to clean code and potential scalability in the future.
This is something I don't currently have experience with, although the idea sounds relatively straightforward. As new data is available (as user inputs change), rebuild the chart to include this new data. Luckily Chart.js includes out of the box animations for events like this, a vue-chartjs even includes two mixins to support reactive data. As I've seen in other demos, I foresee this making the most sense to include a short pause between a user input and when the chart is recreated to prevent scenarios (such as if a user input uses a slider) wherein the chart is attempting to regenerate hundreds of times in a fraction of second. I'll save this tidbit for when I'm further along, but felt it was worth mentioning.
At the end of the day, if the only input my calculator supports is linear compounding, then I've really not made anything remotely useful. I'm not trying to reinvent the wheel, but there's a range of questions which can help produce a more accurate, or at least realistic calculation, given all of the factors that one would expect to influence savings over time. Once I have all of the other pieces in place, I can refine the calculation to better adapt to different scenarios.
I've always been a fan of modern web design, and one of things I do well is designing elegant and functional pages. While the focus of this project is more learning and the underlying code, I would be remiss if I didn't give it a nice "coat of paint". Lastly, although the gameplan is to build everything in a scalable, adaptable fashion, I won't deny that the "first pass" of the code may not be the most efficient. Hopefully, by the end of this experiment, I'll have a base of knowledge for which I can build upon.
