Lightning, what's the preferred way to bind output text? [Best Practise?]

Question

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 */
$A.log(cmp.get("v.textValue"));

and

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

/* componentController.js */
$A.log(cmp.find("textValue").get("v.value"));

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?

Answer 1

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/ .

Answer 2

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.