FormidableLabs
Consider non-global cache strategies
Capturing an out-of-band conversation with @ryan-roemer:
Using a global singleton for the cache strategy is potentially undesirable. Or, inversely, it might be desirable to use different caching solutions for different components / pages in the context of a single Node.js process.
If the traversal functions in src/render/traverse.js were made to be class methods of a new Traverser class, a cacher object with methods get and set could be attached to the instance to simplify access to the custom cacher.
This could be provided as a replacement to setCacheStrategy or as a complement. If a complement, setCacheStrategy would set the global cache strategy. This value would be overrideable by passing a Cacher to the Renderer constructor.
This is probably a better design, but also a nice-to-have, since a global caching strategy is probably adequate for the vast majority of use cases.
See also: https://github.com/FormidableLabs/rapscallion/pull/36#discussion_r101206443
This should be relatively straightforward now that the Renderer is easily exposed to its Sequence.
👍 , in a more naive caching library (that I shelved as this one is a better design), I implemented cache settings as a decorator to components that exposed settings such as in-memory caching (e.g. elements with few rendered permutations) but would use memcached otherwise.
