Consider non-global cache strategies

[divmain]

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: #36 (comment)

[divmain]

This should be relatively straightforward now that the Renderer is easily exposed to its Sequence.

[clifton]

👍 , 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.