-
-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Block params #3
Conversation
Interesting use of Rubyism here, I kind of like it. |
@mmun can you describe how this would work in HTML syntax? |
@wycats I thinks the HTML syntax merits its own RFC first. A few of my own questions about the HTML syntax:
|
Not a big fan of this syntax... especially if HTMLBars is being designed to be used internally in multiple projects. For one, the Second, it doesn't fix the problem that "Custom syntaxes are not in the spirit of the Handlebars language and require the consumer to know the special keywords per helper." It just moves the special knowledge requirement to a less semantic syntax. Correct me if I'm wrong, but this syntax:
Still requires the developer to know that the for-each helper takes two params, the first being the key and second being the value and is no less complicated than Just like with choosing any API to work with, the onus should (and with this syntax would still be) on the developer to know and understand the syntax presented to them by the helpers they load on the page. How these helpers' syntaxes are handled should be dictated by the author of the helper and all their use cases can be covered by by Handlebar's existing If a helper injects values into the rendered block's context, like the default Also, it means we don't have to add a large amount of functionality to Handlebars, a framework used in many other projects besides this. By allowing block helpers to inject @DaTa into the context of the blocks they are rendering, and letting template authors access @DaTa expressions in their templates: tildeio/htmlbars#98 (comment) we achieve this flexibility with a minimally invasive change. |
@EpicMiller I think this is a proposal for Ember as an extension to Handlebars, so only those using Ember with Handlebars will get this.
Ember already adds a good amount of custom handlebars syntax, so this isn't really an issue. |
Block params have the exact same semantics as the existing data vars: Handlebars:
Proposal:
It just gives you a standardized way to name a yielded variable.
It absolutely does. You will need only to learn only one standardize API to access data yielded by the helper. It also makes writing a helper that yields data simpler as well: you don't have to worry about keywords or clobbering the context scope. Using pseudo-paths like "as" is an abuse of the language that I don't support. It adds unnecessary complications to stuff like Ember's each helper.
No one is claiming it doesn't. It's just like
I think you are missing the point that the helper should not decide the name of the variable. It should be specifiable in the template. |
If it's not clear, in the Handlebars case this feature would be built by using |
I'm not tied to the
In fact, since Ember doesn't support Ultimately the |
@mmun in your own example you use What if by default it worked as @EpicMiller suggested and you'd have the ability to change the name of them like so:
It seems easier to follow. |
What is confusing about it? They're different helpers. @guilhermeaiolfi Your proposed syntax doesn't make sense to me. The whole point of this PR is that the value of |
Ops, sorry. My idea is same, but I missed quotes:
It's just a way of naming the vars available inside the block: |
Oh, I see what you mean. Most languages only support yielding ordered values. I think that's simpler than yielding named ones.
vs.
That said, your proposal is certainly a valid one. |
I do like the idea of yielding the name at the request of the developer. That way the user can consume the default functionality of the helper if they want, without worrying about custom names, but still have the choice of customizing the helper's default interface if desired. So this:
would become
or
Sorry, literally just re-iterated what guilhermeaiolfi said. I don't know if the unordered values make sense to me though. Data attributes inside of block helpers don't have an inherent order to the developer using them. To the person making use of the helper it works more like an object/associative array rather than an indexed array. However, yielding named values runs the risk of getting rather verbose, although its definitely the more legible options over the ordered value options. |
I have not idea of what kind of syntax tricks handlebars can handle, but even being a ruby developer I find this a bit awkward compared with all the helpers I've seen so far. I would try to preserve the style we have right now, with something like @EpicMiller sayd: {{#each people as person}}
{{person.name}}
{{/each}}
{{#each obj as (name age)}}
{{name}} has {{age}}
{{/each}} |
some talk about using |
@cibernox If that's what @EpicMiller meant then I'm definitely on board. The syntax is by no means set in stone and Here are some examples of the kind of style I'd like to be able to do, using your syntax: {{#each items tagName="ul" as item}}
{{#with item.owner as owner}}
{{item.name}}: {{owner.name}}
{{/with}}
{{/each}} {{#each products as product}}
{{#form-for product as f}}
<h2>{{product.name}}</h2>
<p>{{f.input "description"}}</p>
<p>{{f.submit}}</p>
{{/form-for}}
{{/each}} {{#tab-view as t}}
{{#t.pane as p}}
{{#p.header}}...{{/p.header}}
{{#p.content}}...{{/p.content}}
{{/t.pane}}
{{#t.pane as p}}
{{#p.header}}...{{/p.header}}
{{#p.content}}...{{/p.content}}
{{/t.pane}}
{{/tab-view}} |
I'm not a ruby guy...Help me out here. How is this different than:
Or is it more like destructuring?
I think I'm completely misunderstanding, even after rereading the ruby docs multiple times. |
Maybe I get it now. It's all about the existing helpers losing access to the parent context if they need to also provide their own, right? Hence a new syntax to keep the existing behavior intact when desired + compat? |
@jayphelps Yes. |
@mmun , I like it,
and:
|
Update: So far we're leaning towards
and
Notice that we opted for the bracketed approach when yielding multiple values. We found the syntax This RFC would still require parser changes to Handlebars. The desired block mustache grammar should look roughly like:
Great suggestion @EpicMiller and @cibernox :) |
Still not convinced we need to specifically yield values like that... I think yielding multiple values will be far more common than you think. The default #each helper in handlebars defines Rather than specifically yielding values, I like @stefanpenner 's approach of providing the |
You haven't accounted for nested blocks. This is why you must name your params. |
If it makes the parsing simpler because parenthesis are used for expressions, I would also be happy with any other delimiter like
|
Nested blocks:
If you didn't have an
|
I think @EpicMiller's suggestion is easier to read and would be easier to undestand specially for very nested blocks. You wouldn't have to come up with different params names like |
i don't remember saying this |
@MajorBreakfast
makes a whole lot more sense than what shipped and is shown in the blog here:
I fully agree with @donaldpipowitch and @zeppelin that it's confusing and unreadable when there are attributes in between the component name and the 'as' |
I would disagree, having used the |
@knownasilya |
But this reads even worse: <todays-date yields day month year required>
<todays-date> which of these are the yielded attributes? Change it up.. <todays-date required yields day month year>
<todays-date> What's what? Just trying to parse that visually is a mad headache.. |
Just an FYI, we have settled on and I am pretty confident it is finalized as such. <todays-date as |day month year|>
</todays-date> |
I agree. It's done, merged and released in stable for a while, so there is no point in keep discussing what at the end are just subjective preferences. It is a know axiom in computer science that there will never be total consensus about what is the best syntax for a given feature. |
@cibernox not just in computer science 😉 |
@stefanpenner @cibernox well the reason, i'm bringing it up, is that from the example on the release blog, which is the only place the public has it documented, it really is confusing to the point it makes no sense, even EmberSherpa tried to explain it here https://www.youtube.com/watch?v=8GMeMM0ukYM&t=2345 and basically gave up |
@mgenev can you link the second where embersherpa tryes to explain it? I've found the syntax extremely intuitive (I have ruby background) |
Ah sorry, my link didn't work here https://www.youtube.com/watch?v=8GMeMM0ukYM&t=2345, updated above too |
one can think of yielding, as calling a <foo-bar as |baz cuz|>
</foo-bar> is more or less /* content of fooBar */ = fooBar(function(baz, cuz) {
return /* content for fooBar */
}) but in the world of HBS templates. |
I think that the problem in that video is that he was trying at the same time to explain block params and the In any case |
ya other wise it becomes key-word soup <my-component require as foo bar baz class="bar" id="foo">
</my-component> vs <my-component require as |foo bar baz| class="bar" id="foo">
</my-component> and more nicely represented as <my-component require class="bar" id="foo" as |foo bar baz| >
</my-component> |
@mgenev @cibernox want cleaner examples? Help me here to iron out the component composability guide emberjs/guides#66 |
I actually like the pipes delimiter a lot. @stefanpenner why do you think:
is more nicely represented as
since the vars in the pipes refer to what the component yields, not the attributes that precede the 'as' in the 2nd example, in my mind it's a lot more readable the first way |
@mgenev It was hard for me to explain because like @cibernox said, I was explaining component helper & yield at the same time, but also
|
the last step is just my personal preference, but our syntax allows both. So you can do what suites the situation the best. |
@taras can you checkout emberjs/guides#66 and maybe leave some feedback about the oneway binding and yields? |
@stefanpenner in that case i think a good guide is just fine |
btw i'm not just trolling for no reason, even if my communication may come off that way (i'm from the balkans), I really needed clarity because I'm the lead on this book http://www.sanestackbook.com/ and maintain ember demo projects and a stack with hundreds of stars and dozens of forks, |
@mgenev thanks for that, I've been waiting for someone to integrate Sails and Ember in a nice way (non book link) |
Update `Motivation` section per review
Update stages RFC per discussion
Introduce block parameters to the Handlebars language to standardize context-preserving helpers, for example:
Rendered View