-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[FEATURE ember-htmlbars-scoped-helpers] #10244
Conversation
Allows locally scoped helpers to be used in a components layout (or in the template block if using block params). ---- Local Helpers Example: ```javascript // app/components/x-foo.js import Ember from "ember"; var makeBoundHelper = Ember.HTMLBars.makeBoundHelper; export default Ember.Component.extend({ capitalize: makeBoundHelper(function(params) { return params[0].toUpperCase(); }) }); ``` ```handlebars {{! app/templates/components/x-foo.hbs }} {{capitalize 'blahzorz'}} === BLAHZORZ ``` ---- Block Params Example: ```javascript // app/components/form-for.js import Ember from "ember"; import FormForInput from "./helpers/input"; var makeViewHelper = Ember.HTMLBars.makeViewHelper; export default Ember.Component.extend({ formHelpers: { input: makeViewHelper(FormForInput) } }); ``` ```handlebars {{! app/templates/components/form-for.hbs }} {{yield formHelpers}} ``` ```handlebars {{! app/templates/post/new.hbs }} {{#form-for as |f|}} {{f.input label="Title" value=model.title}} {{/form-for}} ```
Nice. |
This is glorious |
Damn... This is awesome! |
@rwjblue awesome, this is pretty much the last blocker for easy-form 2.0 |
One thing I want ask. In my understanding HTMLBars prefers <form-for on-submit={{action "saveUser"}}></form-for> When it comes to |
@darkbaby123 - the <!-- app/templates/post/new.hbs -->
<form-for as |f|>
<f.input label="Title" value={{model.title}}></f.input>
<form-for> |
@rwjblue so this is a bit of a tangent, but if /cc @stefanpenner |
@rwjblue is it possible to access the parent component from the helper callback? |
@bcardarella - Do you mean the @taras - That is not really related to this feature. In 1.10 you can already yield the current component as your block param, and access its properties in the template. Example JSBin |
@rwjblue the Last I recall it was decided not to support this as there was a desire to keep as close to spec HTML as possible. But in light of the syntax you outlined above, if we're no longer considering spec HTML the goal for HTMLBars then I would argue the door should be re-opened on the namespace syntax. If there are no objections then I can write an RFC for this, but I don't want to go through the effort unless it has already been vetted and turned down. |
@bcardarella - I don't remember this having being decided (although I may just be forgetting). We should absolutely have that discussion and officially decide if we want |
👍 |
@@ -33,6 +33,13 @@ export default function lookupHelper(name, view, env) { | |||
return helper; | |||
} | |||
|
|||
if (Ember.FEATURES.isEnabled('ember-htmlbars-scoped-helpers')) { | |||
helper = view.getStream(name).value(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a to ask if this should be bound?
Updates based on discussion with several folks:
|
@fivetanley we've been pretty flat-out on trying to land glimmer. I think this is just waiting in the queue behind that. |
Would it not be more consistent to allow scoped based definitions much like If a
|
@ef4 with Glimmer landed, any updates on the status of this PR? |
I'm still advocating for the more explicit <my-form do |f|>
<f.input value={{name}}>
</my-form> as it does not:
|
@stefanpenner - That is precisely what this PR did when proposed (take a peek at the tests and description). |
yup, but I believe this still lacks.
the last two being the points I think we need to nail before landing. The first can be added later. |
@stefanpenner - The example snippet you typed, is very nearly exactly what was implemented here (without angle-brackets). Example from the description:
Example test is here. |
For me the main issue with this is that I don't know any part of HTML shadow DOM or otherwise that matches this setup, which seems to be something that the Ember community have been pushing for with all the native HTML-ish syntax used. Instead would it make more sense in the declaration of the component to have special meaning when defined within a different component? Much like a normal input would within a form element have a special meaning. I guess I am asking more for the use cases here and how they might migrate to native browser features eventually. If it isn't something that belongs in the remit of HTML then surely it should remain within the framework much like |
AFAIK shadow DOM does not have a corollary. WebComponents to be used only within a shadow root, are global, and pollute the entire realm. We don't believe this to be reasonable, as one component should not pollute the global namespace for its own domain specific sub-components, nor should they need to be names-spaced. Consider, <google-map>
<pin loc=...>
<address loc=...>
</google-map> In web-components world, In theory, we could say Interestingly, If we looked to JavaScript, we would likely express a solution as: formFor(function(form) {
form.input({ label: "Title", value: model.title });
}); Looks similar to the In HTMLBars, we could express the closure and lexical scoping in an aligned way. {{#form-for as |f|}}
{{f.input label="Title" value=model.title}}
{{/form-for}} benefits:
cons:
|
Just chiming in to note that the current implementation of Shadow DOM as implemented in Chrome is almost certainly going to vary drastically in certain aspects to the one that gets finally recommended and shipped in all browsers. The vendors are finally back to the drawing board and discussing it. Node distribution e.g. That said, there does not seem to be any actionable traction on custom elements scoped to a shadow root (which what I think you are all discussing). There's been mention of it and of some sort of namespacing mechanism (unrelated to XML namespaces) but I would guess there's just too much to solve for the simple cases first before they seriously consider either of these. tl;dr I don't believe there will be any analogous in the browser for some time and we may in fact be the trailblazers on experimenting with options that will eventually become standards. |
yes |
@jayphelps and @stefanpenner I was mentioning the usage of Certainly namespacing and so on would be great for things like that. However in your example I would expect something like:
Where
So for example I meant more in the component definition something like:
This is something I have mentioned to @jayphelps before with that Perhaps no one else visualises this separation in the same way. |
@jonathanKingston busy right now so haven't grok'd your entire reply and this thread yet but I absolutely 100% agree that we can and should do things just like browsers do now with respect to elements having contextual awareness. e.g. This pattern has been used in an ad hoc way in Ember since the beginning, mostly with people relying on |
It has been ad-hoc do to how brittle it is when the parent tree topology changes, and life-cycle timings as entangling parent/child during render via view traversal is dubious at best. (as we saw with nf-graph, doing registration in various life-cycle hooks) This relationship could be curried when the parent component passes the child component factory forward. |
This would be really unfortunate, to have apps with hundreds of components some contextual causing my templates to be riddled with This really just boils down to, globals are obviously a foot-gun everywhere, but in the DOM they are deemed OK for some reason. ^^ is so far the only proposal that reasonable solves this. Remember, this is also how react solves it. It does so though, by just using JS's own lexical scoping. This is actually quite a handy compositional primitive. We can – with some effort – apply the pattern to our more constrained DSL. This will allow a nice level composition, with familiar concepts. At the cost of continuing to remain a superset of HTML. |
Agreed. I'm not against the proposal to have "shadow root scoped style" components. I LOVE the idea. Sorry if my spewing of thoughts implied otherwise. I basically hijacked this thread with some FYIs Edit: I see what I said that implied it, my bad. I was just saying that you can and should follow the same pattern the browser does NOW. If this feature lands and you decide you do in fact want to use this it, even better! |
I hope the DOM comes up with something as-well, because collisions with complex apps + sharing components is going to be crappy. |
I think this is trying to solve both namespaces and scope sharing: Scope sharing
I'm not sure if putting this off because of complications is a good idea. However I'm not sure if I get the rationale to not have properties linking components together. I get the feeling if this were to become native the syntax would become similar to:
Which I see being a little cumbersome for template authors to write to relate elements together when this happens already with DOM properties on element relationships. NamespacesI understand the name spacing argument completely (which I am still upset components didn't adopt the XML namespaces which was already implemented)
Ember syntaxAs I noted before my distaste in using HTML-ish syntax for this can we assume the moustache style syntax will be still possible? Again: I'm not against this change so much just not sure if it's going to last the test of time perhaps. |
I believe this just tries to solve scoped |
@stefanpenner Just read through this thread. Am I correct in summarizing your proposal/feedback as:
|
Is there any chance this is going to be part of 2.0? It is a blocker for easy-form 2.0 and I'm don't want to implement a half-way solution until this, or a similar feature, lands. easy-form itself is currently preventing others from upgrading beyond Ember 1.10 |
Yes this is strongly related to the contextual components pr. I believe @mmun may be spear heading some of the early htmlbars side work. This may be a good partof that |
@stefanpenner is there a pr # to follow for that? I don't see any open ones from @mmun |
@bcardarella It's an RFC: emberjs/rfcs#64 |
Closing this in favor of tracking on emberjs/rfcs#64. |
Allows locally scoped helpers to be used in a components layout (or in the template block if using block params).
Local Helpers Example:
Block Params Example: