Closed mquandalle closed 6 years ago
this would be excellent :+1:
+1
would be awesome
Yeah, that would be great stuff!
yes please :)
can this happen please
I would have expected the blaze runtime and the spacebars compiler to bring this functionality earlier. Since it doesn't seem to be a priority for the meteor core team (which I can understand) I'm willing to provide a mid-term solution.
I've been always careful while designing this package to not add some runtime overhead, all operations are done during the compilation and the content sent to the client is then exactly the same as if you used spacebars (and this is how this package is effectively tested).
But I'm willing to do an exception for this feature. I would like to add a weak dependency on the handlebar-helpers by @raix. I'm particularly interested in the $eq
, $neq
, $lt
, $gt
, $lte
, $gte
, $and
, $or
, and $not
helpers. For all of these what I could do is provide syntactic sugar so writing
if player.score > 10
is equivalent to
if $gt player.score 10
This feature would be provided only to raix:handlebar-helpers
users. Thoughts?
That would be nice, if temporary.
Also it’s a pity not to be able to use object mapping to true or false for class names such as li(class={checked: checked, private: private})
. So handlebar helpers such as {{isChecked a b}}
could also be helpful but wouldn’t work anyway for an arbitrary class name such as "private". Just my thoughts...
+1. Any updates on this?
Anything?
:+1: Go go go people!
Indeed, that seems to be a blocker.
I am trying to do something like this :
//Content of formControl.tpl.jade
.form-group
label.park-form-label= label
.park-form-field
if type=="area"
textarea.form-control(name=name)
else
input.form-control(type=type,name=name)
and it won't compile. This is a case where I can't put multiples variables like "isTextarea","isSelect", ...
On the call site it is would be :
+formControl(label="Name" name="name" type="text")
+formControl(label="Description" name="name" type="area")
This is a use case which could show that it is important.
The alternative would be to duplicate code to have one template per type of control!
@programaths No. You can just write a helper for the template and call it "isTypeEqualArea". In it you evaluate your type variable (this.type or just pass it the type varbiable).
+1 would be SOO nice
The fact that this is still not a thing is mindblowing and makes this package pretty useless IMHO.
I've spent a few hours trying to implement this functionality but I ran into at least two high-level non-trivial obstacles:
{{fun arg1 arg2}}
, so we either have to create a coffeescript-ish DSL that support both the previous syntax and the new one or to break the existing code. Breaking the existing code is not as easy as it sounds because we currently use things like ../val
to read a value from a upper context, but there is no way to express this idea in JavaScript — that's because scopes works completely differently in it. And again we could create a DSL that would accept things like ../val[@index]
but that seems unreasonable (if you are not convinced I can find crazier examples). @darrynten if this package is useless to you, use something else. The default in meteor is Spacebars but as explained above it has the same limitations than meteor-jade, and it won't help you with the issue of inline expressions. Otherwise you can try React+JSX which have a strong support in the JS community and a complete JS expressions support. As downsides it is also less integrated with the rest of the meteor stack (especially with tracker) and doesn't have anything like a concise {haml,jade}-like syntax (if you like that).
Would any of the new APIs in Meteor 1.2 help here at all?
Found this page, when searching for an Jade equivalent to Handlebars inline "if's", example: li(class="{{#if checked}}checked{{/if}}")
But then I guess there isn't? Still works thought, so no biggy.
I think the problem is something different. Handlebars is not imperative like Jade. It is a declarative language.
What you are trying to do is mix apples with oranges, or better yet make apples taste like oranges.
In declarative programming we can use helpers or built in functions to do similar things but we need to keep in mind that we are limited.
For those who do not understand what the difference is: http://latentflip.com/imperative-vs-declarative/
It is the same issue if you argue about Less.js vs. Sass. Less does not have native loops or other functions. We can use tricks to do this though. Please note that I myself have used these tricks but I am not recommending this. If you disguise a declarative language with an imperative syntax it does not mean you will have access to imperative programming
Look at these two libs I wrote:
they try to add imperative behavior to Less.js.
@pixelass I agree with you, and I would be against (I would in fact probably write my guides to strongly recommend against) the use of the inline code where-ever possible, and to not treat it as any more than a "fancy data selector".
The main points where I would have people use this feature, are to replace class selectors ("selected", "deleted", etc) and other logic that currently can't even be solved with &dyn (unless you use coffee-jade
or another similar fork). It would be another step just like Unwrapped Templates that allows people to code more efficiently, without having to make many files.
Hi @mquandalle I've implemented (but not anonymous) helpers which can solve most of use-cases, we can try to merge for Jade sugar, see templatehelpers package
+1 Is anyone currently working on this?
It would be useful to be able to define some kind of "anonymous helpers" like this:
As far as I know, it's not yet possible to define this kind of things in the Spacebars abstract tree. So maybe it's more a Spacebars feature? @dgreensp?