In Lightning, with as little custom coding as possible, what is the best way to show a dependent field when a particular picklist choice is selected? Please note, this question is not directly about dependent picklists; rather it's about showing/hiding the dependent field.

I want to be able to define my layouts using the Lightning App Builder, therefore building a custom Lightning component for the whole layout is not what I'm looking for.

One solution that I had before LockerService was introduced was embedding the toggle logic in a hidden component, but I don't think we are supposed to be using this hack anymore.

  • This sounds interesting. Could you provide more details? You should still be able to call methods on a utility component (if I understand your design properly).
    – JF Paradis
    Jul 27, 2017 at 12:53
  • @JFParadis If I select Credit Card from my "Payment Method" picklist I want the Card Number, Expiry Date, and CVV fields to show. Conversely if Cheque is selected I should see only the Cheque Number field. I can create a custom Lightning component and control the display, but that takes the App Builder away from my users which is a big problem. What I used to do was include a hidden component in my Lightning Record Page that modified the DOM on demand. But I realize this is hacky and not recommended. So I am looking for options.
    – Mossi2
    Jul 27, 2017 at 21:49

1 Answer 1


@Mossi2, your questions one kay aspects of the platform: encapsulation.

  1. We all try to follows that core OO programming concept. For components, this translates into concepts like shadow DOM, something we try to implement with Lightning components: in not so many words, we should not peek into anther component DOM content.

  2. However, and the DOM is like a giant global. The original specifications never envisioned that it would be used for what we do today, and the proper hooks are missing for proper encapsulation. It's coming though.

Bottom-line: we have to pragmatic, it's not always possible to follow the OO rules because of the legacy we have to deal with.

  1. With LockerService, we took a middle approach: we do not allow you to see the DOM elements from other namespaces, but allow you to peeking into other components that you own (i.e. in your own namespace).

  2. Therefore, if the credit card component is yours, then you can still "break encapsulation" and change its DOM. If it's not in your namespace you can't.

  3. Credit card information is a sensitive subject. If the designer of the component you are using doesn't allow the features you are looking for, then you can't remedy it. That's what LockerService was designed to do, for security reasons, but also for overall stability of the paltform.

If you want a different behavior, then you need to use a different component.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .