this in templateRendered

[zimt28]

I had something like this.find('#mainContent') in my Template.rendered function. When I just convert the code to coffeescript and space:ui, I would like to have the same data context. this in the mediator's templateRendered function seems to be the mediator object itself. Is this intended? Can I access the "normal" context somehow? This might be the same for other functions on the template.

[DominikGuzei]

Hey there again! :smile: Yeah you can access the template / mediator within helpers in several ways:

# Note the single arrow function here! this become a normal template helper
isToggleChecked: ->
  # 'this' is the template instance here
  if @hasAnyTodos and @allTodosCompleted then 'checked' else false

# Here we use the double arrow which binds the function to the mediator instance
# but every mediator has its template instance assigned as @template
isToggleChecked: =>
  # 'this' is the mediator instance here
  if @template.hasAnyTodos and @template.allTodosCompleted then 'checked' else false

# If you prefer the template scope but also need info from the mediator
# you can access the mediator directly over the template instance
getSomething: ->
  # 'this' is the template instance here
  @mediator.store.get 'something'

you can even access the mediator from within "normal" template helpers:

Template.yourMediatedTemplate.helpers
  getSomething: ->
    # 'this' is the template instance here
    @mediator.store.get 'something'

this is because a mediator does nothing but register the functions you provide as template helpers like you would yourself :wink: . So there is not much magic here.

[DominikGuzei]

By the way, you can also use all other lifecycle methods of templates within mediators:

class MyMediator extends Space.ui.Mediator

  # the managed blaze template was created
  templateCreated: (@template) ->

  # the managed blaze template was rendered
  templateRendered: (template) ->

  # the managed blaze template was destroyed
  templateDestroyed: (template) ->

[zimt28]

Thanks for the information :) But for me both templateRendered: -> console.log @ and templateRendered: => console.log @ log my mediator to the console, not the template instance /:

[zimt28]

By the way, do you think this will have some effect on space:ui? Is there something that could be simplified?

[zimt28]

And why is it @template in templateCreated: (@template) ->? :)

[DominikGuzei]

Hey @zimt28 that's on purpose, you always get the template instance as first parameter. templateCreated: (@template) -> is the standard (for all mediators) which assigns the template instance to the mediator instance. Later you can access it anywhere via @template (think: mediatorInstance.template)

[DominikGuzei]

The new Blaze features will make working with space:ui even more awesome :wink: but they don't solve any of the problems that space:ui is solving. The only difference for me would be that I might consider using more of the "normal" template helpers again because its easier to declare internal state variables then. space:ui is all about architectural concerns – the question is always the same: where does the business logic live? I don't think the answer is view components.

[zimt28]

Ok, thanks for your answers :) I'm about 70% done converting my app to space:ui and love it so far! I just close this and create new issues if I have new questions :)

[DominikGuzei]

Awesome, I am glad it helps you :smile: I have some great ideas for the next major release, inspired by the work on space:cqrs – type checked actions! It saved me a ton of time on the server to check all messages that flow through the system before sending them. This way you can't so easily break parts of your application by changing the API.

My biggest problem with actions so far is, that there is no place where it is declared which params they take / require. So it can become confusing how different parts of the app expect certain actions to look like