Wishlist: support {{#Surface class="{{type}}-header"}}

[arboleya]

I can't get to evaluate a variable and set it as a class attribute for a Surface.

Shouldn't this work fine?

<template name='main'>
  {{> header type='testing'}}
</template>

<template name='header'>
  {{#Surface size='[undefined,30]' class="{{type}}-header"}}
    Hello World
  {{/Surface}}
</template>

.testing-header {
  background-color: hotpink;
}

[gadicc]

Mmm, no... Meteor doesn't support that out of the box, e.g. you can't do something like:

{{>someTemplate class="{{type}}-header"}}

and we plug into that same system. However, we do do some other custom stuff on values, and I think we could add support for things like this too. Makes sense and would be cool, I'll look into it over the weekend.

[gadicc]

For now you can just do class=classTypeHelper, etc and set it up with Template.header.helpers().

[arboleya]

Oh now I see the difference, thanks for the prompt answer! And also for the insight, it worked just perfectly :)

Dude, this library is awesome, keep up the good stuff! :beers:

[gadicc]

Thanks for the kind words... everyone's enthusiasm is keeping me working crazy hours on this hehe.

Wow, so, I totally forgot that I did actually start working on something like this in https://github.com/gadicc/meteor-famous-views/commit/0d4fe1bde3542f144e8e040ddebfdc1b77abab56; you can do stuff like class="{{isSelected 'value'}} etc. It only works when the entire string is a single blaze helper though.

The case you described is more complicated, because we need to setup reactive dependencies on just part of the string. Not impossible, but a lot of work.. hopefully we can plug in to how spacebars is doing it though. For now, since there is an easy workaround, this is low priority, but since I agree it's very Meteor and would be cool I'm leaving the issue open for when I have a chance.

[splendido]

actually stuff like

<input id="at-field-{{_id}}" class="at-field-{{_id}}" name="at-field-{{_id}}">

seems to be working for me. See here for example. On this line there is no class="at-field-{{_id}}" actually but I've just tested it and it worked.

Not sure whether this might contribute to the discussion, but your first answer @gadicc seemed weird to me at first, so I wanted to check ;-)

[splendido]

oh, perhaps now I see the difference. The example above is about passing parameters to templates and not directly on DOM elements?

[arboleya]

@splendido Exactly, the input in your example is not a Helper like the {{#Surface}}...{{/Surface}} one.

[arboleya]

@gadicc Very nice. I agree that it's totally not a high priority now, the workaround is quite simple. I was wondering, is there a Roadmap or something of all ideas you want to put into this project?

[gadicc]

Haha @splendido yeah sorry I should have been clearer, but yeah.

@arboleya there was one, I think all the big ideas are implemented now. I think all the smaller ideas that are upcoming are still around as open issues. Anything you were interested in?

I guess in the long term I'd like to see work on related projects that use this lib, e.g. there are a few works-in-progress like https://github.com/gadicc/fview-demo, an upcoming live code editor, and in the super long term, I'd eventually like the equivalent of ionic but for Meteor using Famo.us and responsive animations, etc... e.g. lots of pre-made components to use as building blocks for a full app. But that's stuff you shouldn't expect for another year I think :> The move to famo.us mixed mode is going to be a big one and I'm not sure how it's going to affect us yet.

[arboleya]

@gadicc Not yet, I'm just getting started with it. Perhaps soon I'll have some ideas, I'll let you know.