So I'm going through a lot of the Lightning guides, and even through the reference documentation, and I'm coming across a bunch of inconsistencies, and it's either not explained why, or there are already multiple ways to do things.

To be specific, I'm talking about the difference between something like this:

/* component.cmp */
<aura:attribute name="textValue" type="String" />
<ui:inputText value="{!v.textValue}" />

/* componentController.js */


/* component.cmp */
<ui:inputText aura:id="textValue" />

/* componentController.js */

This may be answering my own question here, but the only difference is that the first example is creating an attribute, where as the second one is purely for when the attribute cannot be set externally.

Would it be fair to say that best practise here extends to what you elements you want to expose externally to other components/apps that are including the element?

BONUS QUESTION: What's the point on using "ui" elements when using LDS?

Example: Look at the LDS guide for buttons vs. the aura reference for ui:button (https://< your domain here >.lightning.force.com/auradocs/reference.app#reference?descriptor=ui:button&defType=component). ui:button doesn't look to have any support for svg elements (no fancy icons in your buttons!), where as you can pretty much roll your own svg button component. It seems a bit strange that I'm stuck having to roll my own button component to get an SVG element, as per the Lightning Trailhead project for using LDS

Looking at the live auradocs reference on the web, vs. the mydomain version, it looks like there's some features that just aren't in Salesforce yet, so maybe that's the answer there too?

  • 2
    As per my opinion looking at an example where it involves inputText/outputext may not be the right way to compare attribute vs component ID. Yes you can find and get/set value using ID in a client side controller, but aura:attribute supports more than just string,decimal,integer it supports arrays, objects etc..developer.salesforce.com/docs/atlas.en-us.lightning.meta/….
    – Rao
    Commented Nov 5, 2015 at 23:43
  • 2
    You can use <aura:attribute> to create a type="Account[]" and pass a javascript object and iterate over the list of accounts, so I would aura has a broder scope
    – Rao
    Commented Nov 5, 2015 at 23:51
  • Yeah I've done that research too and I realise that you can pass more things into the aura:attribute, but this is more a question of best practise. i.e. If I can put anything in an aura:attribute, it doesn't necessarily mean that I should.
    – Ben Naylor
    Commented Nov 6, 2015 at 0:29

2 Answers 2


My experience has been that you would use the custom attribute approach if you wanted to expose the value to be set externally by the container (an app, another component, etc.) of your component. One benefit of that would be that the container could "share" the value across multiple contained components if need be like in this question. You can also do fun things like set the value through an URL parameter.

The value attribute that you can get from the ui:inputText (v.value) is itself an attribute of the abstract ui:input component and already exists to hold the value, so if you have no need to expose it as part of the component's shape / API, then you shouldn't.

Bonus Answer

I have no insight into the roadmap or anything like that (maybe someone from Salesforce will answer), but I tweeted the same general question about LDS, the sldsx components, and the ui:inputs. You can see it in this conversation, but the telling part to me is that the Salesforce1 Style Guide that used to thoroughly list all of the Salesforce1 styles with an URL of http://sfdc-styleguide.herokuapp.com now redirects to https://www.lightningdesignsystem.com/ .

  • 1
    It feels good knowing that someone else is thinking along the same lines. Being the first in our team to learn this stuff is both good and isolating, so it's good to see someone's thinking along the same lines.
    – Ben Naylor
    Commented Nov 6, 2015 at 0:24
  • ...also that Salesforce1 thing is very telling. You also can't get to the desktop app version of Salesforce1 (the old /one/one.app), make me feel that this is part of the same thing also.
    – Ben Naylor
    Commented Nov 6, 2015 at 0:26
  • 1
    Ben, we decide between lightning desktop vs. S1 based on the browser's user-agent. Tell chrome to say it's a phone, and you'll see S1. Commented Nov 6, 2015 at 4:02

In the following thread Lightning Design System is overridden by styles from app.css you can find the answer that LDS is not fully integrated with Lightning Components yet and they working on it. But who knows when they finish... So I think the best way to leverage LDS with Lightning Components will be using sldx components for now.

You must log in to answer this question.

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