Caching

[bchurchill]

Right now, every date is computed from scratch. One nicety is that we can compute provisional dates for future years based on the 10 July 2014 letter, but there are some downsides:

• Client-side performance might suffer.
• Subtle bugs in the browser's javascript interpreter could cause erroneous dates. This isn't very likely, but it could happen after an urgent security update, for example. Javascript isn't very good at being reliable across platforms.

So, a totally reasonable thing to do would be to cache the computed values for all the years corresponding to the official dates provided by the Baha'i World Center. This offers two obvious advantages:

• The client will be much faster
• We can be 100% assured that the dates will match the official ones, even if there are subtle bugs in the client-side javascript interpreter (e.g. floating point arithmetic mistakes).

[bchurchill]

@brenmcnamara in your opinion, how should this be organized in the code base? My guess is that there are three things to be added:

1. JSON data for the fixed dates of Naw-Ruz, the Twin Birthdays
2. Code to generate the JSON data
3. Code that decides whether to do a computation from scratch or use the cached value (i.e. the caching logic).

I feel like the first and third items are straightforward -- we could create a CacheData.js file with the JSON and Cache.js which has a class that accesses it (not exported). That leaves the second item, which is the code that generates the JSON file. This would be some code that isn't shipped as part of the BadiDate module, but would be run as needed (perhaps as part of an npm job). It's not really an "example" though. Do you have any suggestions?