Pass "Template instance" to event-callback and template helpers

[Phil Cockfield]

I'm looking at the methods listed in the documentation under "Template instances".

It says these methods are only available from the this context of the created, rendered and destroyed handlers.

It would be extremely handy to have these available to the DOM event handlers as well, for example:

Template.foo.events

  'click .my-class': (e, tmpl) -> el = tmpl.find('.selector')

Probably harder to do this in the template helpers, because the DOM elements have not been constructed yet (right), but certainly in the events callbacks I'm finding myself wanting to access DOM elements all the time.

Would this be possible - or is there already a prescribed way to do this?

Thanks!

[Theodore Blackman]

I agree that something to do this would be helpful, but I think one problem with this right now is that the `this` in the event handlers and template helpers is different from the `this` in the `created`, `rendered`, and `destroyed` helpers, and that actually makes sense in a way, since the `this` in the helpers is about the data context with which the template is rendered, while the other functions are about the template instance itself.  It would be great if this were more consistent, though; I had a few bugs due to switching back and forth there, since I often move code back and forth between the lifecycle handlers and the helper functions during development.

IMO, any really good solution here would also let the event handlers and template helpers get access to the parent template and the parent data context.  This would address a whole slew of issues that people (including me) have been having with rendering more complicated data structures.  Maybe the right thing to do would be to standardize the `this` for all the template functions to refer to the template instance itself with an extra `parent` variable pointing to the parent template instance, and then the template renderer could use the `template.data` for the `this` inside the templates themselves (if it doesn't already...) so as not to break everything.  Not sure how difficult that change would be on the spark/Handlebars side of things...

Another possibility would be to add references `templateInstance` and `parent` to the data-context `this` in the event handlers and helpers.  The parent there would point to the parent data context, which I think is used much more often than the parent template instance.  That would also be a much more minor change to the API, and my hunch is that it would be significantly easier to implement. 

I see the issue with the DOM elements not being constructed yet, and don't have a good solution.  I've used Meteor.defer to get around this in the past, but it felt really hackish.

[Phil Cockfield]

Yes totally!  Being able to get a parent ref that let's you walk up the hierarchy would provide an enormous amount of flexibility when aiming at more sophisticated rendering scenarios.