I would like to create a component that takes an object as an argument and the path to the relevant property. Then, inside the component I could us this object.property combination to render my object. For example:
//templates/components//make-bold.hbs
Your <b>{{object.dynamicProperty}}</b> property
Person p = Ember.Object.create({ firstName: 'Andrew', lastName: 'Schoewe'});
Later on I might change my mind and want to make the last name bold. Without having to change my component, I could simply change the arguments passed to the component. Like so:
Make-bold should be a bound helper. The dynamic property portion of this question is what is throwing me off since your example above doesn’t convey the need for a dynamic property. Can you explain your real use-case?
I’d like to implement a fast select-input that works well under the new glimmer engine. I was going to do this with a custom component. The path to the value and label of the select options is the dynamic part. I’m also struggling with how to make the component arguments use one way binding. Unfortunately angle-bracket components with one-way binding is a few releases away.
As you’ll see below, I’m interested in the ‘select’ element. Looking through your other recent posts, I see you recommend the open-source x-select component. I’ll give it a shot -no sense in remaking it myself. I just hope x-select is fast!
You don’t have to make them one way, though I’m not arguing it’s a bad idea to do so. You can use mut to indicate a two way binding it’s explicitly mentioned for inputs in the 2.0 RFC ( search mut ).
Right… I’m aware of the ‘mut’ keyword to indicate two-way binding. But is there a way in a handlebars template to indicate a one-way binding? I only know how to do one-way bindings in the Javascript ‘backend’ of the component… but I’m not sure how that would work with component arguments.
Ah I see what you’re getting at, no I don’t believe there is currently a way to have those component bindings be one way in the template layer. As you mentioned you would probably need to do computed.oneWay() in the javascript layer.
@jasonmit, it was my impression that unbound is more “one time” as opposed to “one way” since after it is rendered no direction is bound ie if you change the data in either direction the view will not be updated.
Partially yes. By passing it as a subexpression you’re now essentially passing the literal. Therefor it will behave “one-way” upwards but is still mutable downward.
Yeah, I would say use one of the 20 or so select components out there: Ember Observer and contribute back to the one you like the most The power of OSS!
Forgive me if I’m misunderstanding but doesn’t mutable downward mean that changing the value of name in the parent component should change the value of name in the child component which this doesn’t seem to JS Bin - Collaborative JavaScript Debugging.
Will do. You seem pretty knowledgable about this stuff. Do you have any idea which one of these add-ons is the fastest select input? The component design of emberx-select appeals to me but performance concerns me. I have a lot of selects to display on one screen.