Render method should take tags

[raymond-lam]

The parse takes a tags argument, which overrides mustache.tags. There is no way to pass in a tags argument into the render method, however. In addition to the unfortunate asymmetry that this causes, this has caused some amount of confusion/concern with regard to the caching behavior of parse. See issue #669 for more discussion.

[raymond-lam]

The more I think about this, the more I am in favor of the changes proposed here and in issue #669. The README.md actually suggests using parse as a means of overriding Mustache.tags for rendering a particular template, but this violates the Single Responsibility Principle; parse should take a template and some arguments (namely tags) and, well... parse... and nothing more. (We of course cache for performance, but the cache should be correct and behave as expected.)

Adding tags to render to "compensate" for "correcting" the caching behavior brings us closer to Least Astonishment: render will render according to the template, other arguments it is given, and Mustache.tags if it is not overridden by such arguments. The arguments and Mustache.tags are totally transparent to the caller. More Astonishing than this is render behaving depending on the template, arguments, and maybe Mustache.tags unless an opaque/hidden value was set by calling a different method whose original and main purpose was not actually to override Mustache.tags for all subsequent render calls.

Thanks to @mbrodala and @ilkovich for suggesting this.

[phillipj]

Couldn't agree more with your rationale above. Glad you've found an improvement that doesn't require the using developers to grasp the interconnection between .render() | .parse() | .tags 👍