[blaze] Passing Parameters to Template Inclusion

[Phil Cockfield]

I've been watching Chris Mathers super helpful videos about Blaze/Shark on Evented Mind.  I wanted to clarify how parameters now get passed from a {{> }} template inclusion as it appears that it's changed since the video:

https://www.eventedmind.com/classes/meteor-shark-ui-preview/meteor-rendering-with-the-inclusion-tag

In the lesson Chris shows how the following would get passed into the template helper as parameters:

<template name="hello">

  {{> greeting "joe" "smith" salutation="mr" }}

</template>

Template.hello.helpers

  greeting: (firstName, lastName, options) ->

    console.log firstName, lastName, options

However, I find that if I include parameters like this I get a compile error on the template, saying what it's expecting is a function to be passed as the first argument which is subsequently used for the parameters.

When I do something like that, eg:

{{> greeting myFunc "joe" value=123 }}

Template.hello.helpers

  myFunc: (args...) -> console.log 'myFunc', args

I can see the values getting passed through to that function.  myFunc emits this to the console (with Spacebars.kw containing a hash with the options in it).

["joe", Spacebars.kw]

---

I don't get how to use this.  I'd like to somehow get the arguments piped into the greeting function.  However I can't see how to get access to args, and don't understand what the additional first-parameter-function is for.  Also, I can't see any examples of parameter passing in the Using Blaze wiki.

Am I missing something?  Thanks everyone.

[Phil Cockfield]

After chatting with Keith Nicholas I realized that if I do this (ie. not a {{>}}):

{{ greeting myFunc "joe" value=123 }}

I get the arguments passed through as expected.  But then I'm back with the problem that the returned template is not rendered to the DOM as a "live" reactive template, it just emits 

[Object object].

[Phil Cockfield]

After chatting with Keith further last night, Keith figured out something like this would achieve the desired result, but to do this feels like I'm pushing against the intention of the blaze design.  

Is this the wrong way to go about it?  Or is there another pattern that the arguments pass-through function is designed to enable.

This is posted here: https://github.com/philcockfield/blaze-02/commit/9df6ab89c19ec633d557d5354f742858d1b1dfa9

<template name="hello">

  <div class='hello'>

    {{> greeting args 'joe' 'smith' salutation='mr' }}

  </div>

</template>

<template name="greeting">

  <div class='greeting'>

    <div>

      <strong>Greeting</strong>

      <code>{{ title }}</code>

    </div>

    <button class='btn foo'>Foo</button>

  </div>

</template>

 

Template.hello.helpers

  args: -> { args:arguments }

  greeting: ->

    console.log 'METHOD: greeting'

    console.log '@', @ # Prints: { args:array[3] }

    console.log ''

    data =

      title:'hello'

    UI.With (-> data), Template.greeting

Template.hello.events

  'click .btn.hello': (e) ->

    console.log '!!HELLO click'

    console.log '- this', @

    console.log ' - e', e

    console.log ''

Template.greeting.events

  'click .btn.foo': -> console.log '!!FOO click', @

[Avital Oliver]

Yeah, the way you pass arguments to inclusions sucks. We need to fix that.

Parameters to inclusions are always passed in the data context. You basically only get to use keyword arguments (or *one* positional argument). Sometimes you need to do some juggling in the form of an additional argument with the value `..` to be able to access both the arguments and the data context at the point of insertion. For example, Eric Dobbertin also hit this problem and found a workaround: https://groups.google.com/d/msg/meteor-talk/F9XivhCqWvY/G-AQRbk4AfIJ

Does this help?

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Phil Cockfield]

Hey Avital,

Thanks, seeing what's going on the thread you reference is helpful. 

And also knowing that the way params are working is not ideal in your mind yet (ie. that I'm not hitting a wall because I'm totally going down a rat hole).

I'm wondering, given you say you want to fix the way args are passed to inclusions, should I hold off on my port until those changes drop?  Or are you thinking about a fix to that further out on the horizon?

Cheers!

Phil Cockfield
https://respond.ly

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/SmdnPOEhJgU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Avital Oliver]

I don't know yet when that change will land.

[Dan Dascalescu]

I've just answered a StackOverflow question on passing constant parameters into templates, and thought I'd share here how this works as of Meteor 0.8.3:

<div class="slot-wrapper">
  {{> slot number="1"}}
  {{> slot number="2"}}
  ...
</div>

<template name="slot">
  <div>Machine name: {{../name}}</div>   {{! `name` is a property of parent data context}}
  <div class="number"><span>{{number}}</span></div>  {{! `number` was passed directly by the caller template as a constant object}}
</template>

On Tuesday, April 22, 2014 1:46:15 PM UTC-7, Phil Cockfield wrote:

I've been watching Chris Mathers super helpful videos about Blaze/Shark on Evented Mind.  I wanted to clarify how parameters now get passed from a {{> }} template inclusion as it appears that it's changed since the video:  [...]