I need to decide which path to proceed:

  • <ui:inputSelect />
  • <lightning:select />
  • <force:inputField />
  • <lightning:input /> (Beta)
  • write my own component...

Use case:

Mass edit of n records in a table done by <aura:iteration>. Must be capable of working in nested iterations, too. Data should be bound easily to a field of a list of SObject I am iteration over. Picklistvalues should get populated as easy as possible and respect translations, fielddependencies, etc.

PART ONE - ui:inputSelect vs. lighning:select

I've seen this post Difference between lightning and ui tags

The accepted answer refers to the the Winter 17 release notes here

You can find base Lightning components in the lightning namespace to complement the existing ui namespace components. In instances where there are matching ui and lightning namespace components, we recommend that you use the lightning namespace component. The lightning namespace components are optimized for common use cases. Beyond being equipped with the Lightning Design System styling, they handle accessibility, real-time interaction, and enhanced error messages.

But to decide which one to use, this is far too general to figure the exact differences and decide which one to use.

What I've seen so far:

  • Eventname for onchange: ui ==> change , lightning ==> onchange
  • Tags for options: ui ==> <ui:inputSelectOption> , lightning ==> <option>
  • lightning:select seems always to render a label even with blank label-attribute, it consumes space for an empty label and messing-up rendering inside of tables.
  • What else?

Why do we find these differences?

Why Salesforce changed these things? (Now it's hard to switch an compare the two of them). Why salesforce has introduced two different flavors of the same? This is highly irritating for beginners.

Are there differences in data-binding and event-handling?

My observation on ui:inputSelect is, that if you just assign a value like <ui:inputSelect value="{!v.whatever}" /> it does not get (default)selected on the UI. Is that improved on lightning or am I doing something wrong for ui and that data-binding should work even for both?

Best Practice to choose?

Should we even care on ui or might the answer be: just forget about ui namespace for new project! Always use lightning namespace. ui is just for backward compatibility and legacy first-generation-lightning-components? Is that true? I'm somehow reading between the lines and would like to become clear on that.

Best Practice to simply display SObject Picklist Fields? (USE CASE NO. 1!)

Honestly I find both of them very unsatisfying. Coming from Visualforce and using <apex:inputField> for one decade, this feels like back in the Stone age. What is the state of the art very best we can actually do to simply render an SObject Picklist Field with all of it's

  • Schema-defined Picklist Values OR Global Picklist Values
  • Field Dependencies

Do we really still have to do something like this http://www.sfdcmonkey.com/2016/12/05/how-to-fetch-picklist-value-from-sobject-and-set-in-uiinputselect/

That's ridiculous compared to Visualforce.

PART TWO - Alternatives?

There are more Alternatives to choose from:

I had my sad experiences with <force:inputField> in the past and read about long standing Known Issues. I simply gave up on it. Of course I need to use it in <aura:iteration>. Is there any hope for this to get mature? Like at all, I mean?

There is a new kid on the block <lightning:input> (Beta). How high I could raise my expectations? Are my expectations too high and should I get used to the absence?

Finally write my own select-components?

I would like to avoid it. But has anyone done it and came up with something better than what we can get out-of-the-box?

  • for a prebuilt select done well as well as other components check out lightningstrike.io. The autocomplete single and multiple is a fav of mine
    – Eric
    Sep 5, 2017 at 13:00
  • @Eric strike look really COOL! I will definitively have a look on that. Eric, one more question: I noticed, that neither in the ui:inputSelect nor in lightning:select there is any data-binding. It seems to be missing at all, so we have to use the (on)change event to backfire the update in our data-model (compo-attribute) - which is another ridiculous thing that we have to do in on our own. The select-compo should take care on proper binding! Now in STRIKE: is there any out-of-the-box binding?? It would be soooo cool!
    – Uwe Heim
    Sep 5, 2017 at 14:16
  • Define your context for "data binding". The value attribute does bind in all the components so a bit confused and don't want to assume. Strike works like you would expect a component to though so I am confident it will do what you want.
    – Eric
    Sep 5, 2017 at 14:20
  • @Eric You are right with that databinding context. An example would be necessary to see what I mean and this question is already over used. I will need to ask a different question or find someone on my team to ask it for me. I will post the link here to keep this one cleaner.
    – Uwe Heim
    Sep 5, 2017 at 14:25
  • On TrailheaDX conference they have said that for winter 18 they are expecting to have <lightning:inputField> which should be the lightning equivalent to <apex:inputField>. I though it should be AMAZING!!! you can see also in the Lightning roadmap page that this component is on the roadmap. BUT I cannot find it in the winter 18 release notes. So I was disappointed, but just for you to know - it should be there sometime, and this should handle all your fields including picklists. Sep 7, 2017 at 6:33

1 Answer 1


I go pragmatic here, with an extra level of indirection to try to cope with the shifting sands of Lightning.

If I'm not sure, then I write a custom component which delegates to the lightning: version.

So, for example, I have a custom date input component like this:

<aura:component implements="flexipage:availableForAllPageTypes,c:FormQuestion" access="global" extends="c:FormElement" >
    <div aura:id="container">
        <lightning:input aura:id="inputField" type="date" value="{!v.value}" label="{!v.question}" required="{!v.required}" messageWhenBadInput="{!v.errorMessage}" messageWhenValueMissing="{!v.question + ' is required'}" validity="{!v.validity}" />

When Winter 18 is out, I can just swap in the <lightning:formattedDateTime> component instead of <lightning:input> and add any custom logic along the way to handle any oddities required during the delegation.

It does mean more components, but I think the extra layer of abstraction is worth it for now. Once the components are all out of Beta, then we can breath a sigh of relief!

  • nice general wrapping approach but doesn't really answer the question on which compo to choose for picklists...
    – Uwe Heim
    Sep 5, 2017 at 16:36
  • Today, I use <lightning:select> inside a wrapper. My impression is that the force and ui ones are going to be deprecated one day. And that lightning:input is spaghetti ball which, release by release, is turning into separate components.
    – Aidan
    Sep 5, 2017 at 16:38

You must log in to answer this question.

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