It’s important to realize that each movement (flexion, extension, etc.) has a related opposite movement. For example, flexion is paired with extension, right lateral bending is paired with left lateral bending, and right rotation is paired with left rotation.
When ankylosis is NOT checked, all text fields are enabled.
When ankylosis for a specific movement is checked, then its opposite movement must be disabled. For example, if the user clicked Ankylosis for flexion, then the entire extension input field and checkbox need to be disabled.
For this reason, each rom-field indicates its “opposite” control. Each rom-field is using an observer, so when a checkbox is checked, it gets notified, and I have access to all the details about the rom-field. However, when a checkbox is checked, I need somehow to notify the rom-group, so that it can look-up the opposite rom-field and disable it.
I cannot figure this puzzle out. Does anyone have any suggestions on how to send a message to the component’s parent without tightly coupling them?
There’s actually a feature in Canary (behind a feature flag) that is the implementation of this RFC that would help in this scenario…but for now, the one piece that you’re probably looking for is an emerging pattern in which you yield the “public API” of the parent component. In your case, it sounds like you need two things — first, a way to notify the parent that a field has been enabled, and some data yielded that describes which properties are disabled.
So, that might look like this (I’m leaving a bunch out of this — but hopefully it gives you a starting place):
Then, your rom-field component will need to send that action (since it’s an action property, you’d do this.getAttr('enable')('fieldName')), and you’d need a way to determine wether that field is enabled based on the enabled fields data.
Thank you for responding. Do you mind elaborating on a few concepts that are new to me?
I’m not clear on the {{yield (action fieldEnabled) enabledFields}} line. I understand the yield, but what does the action do.
I’ve tried to lookup what is going on with the 3rd part, {{#rom-group as |fieldEnabled enabledFields|}} but I’m familiar with the “as” only as it pertains to #each. What is that actually doing?
Would you be able to provide a little more description of what’s going on in each of those small code snippets?
So, the action helper takes a function as an argument and makes sure that it is properly scoped for when it is later invoked by something else. I think that this blog gives a decent overview of the feature.
So, if you just passed that function directly — when it was later invoked, it would not be invoked in the parent component’s context. If you pass that function into the action helper first, that will essentially bind that function’s scope to the parent component.
If you take a look at this twiddle, you can see the difference of when you use the action helper vs when you don’t: Ember Twiddle
In regards to the “as”…this corresponds to what you pass to the yield. So,
Thank you so much. The ember-twiddle was perfect, and I think I get it now. So, basically, the yield is passing parent parameters to the child. So, when something changes, the child can now execute the closure, which is actually in the parent.
I will tinker around with this and see if I can make it work. Thank you!
OK, I have this partially working - when a checkbox is checked, it is now calling a parent component function with the id of the opposing control. How does the parent then disable that control? I am sure I could figure out a jquery way to do this, but is there a clean Ember way to do this?
I think that if the parent component yields the list of ids that should be disabled, then the child components can compare itself against that list to see if it should be disabled.
Here’s a quick mock-up of what I mean: Ember Twiddle
That is extremely helpful and very generous of you to take the time to put the mock-up together for me. I understand how it works except for one small detail that maybe you can shed light on. In the parent, the collection of disabled id’s are kept in an Ember.computed. What is the reason it must be in a computed?