Thank you to everyone who attended our last webinar, Building a Single Page App with Lightning Components. We learned about:

• Using base components instead of creating your own
  
• Navigating with a single page application using Lightning Component Events and CSS
  
• Creating a more dynamic experience by injecting Lightning components in real time
  

Here’s the recording:

We had more questions than we had time to answer during the webinar, so we’ve published the top questions from our Q&A in this blog post.

What’s the difference between UI tags and Lightning tags?

You can find standard 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.

Is there is any chance to use StandardSetController for creating pagination in a Lightning component?

StandardSetController is only currently available for Visualforce Pages. To include pagination on a Lightning component, currently the best approach is to do it from your server-side Apex controller using SOQL OFFSET on your SOQL queries.

Is it possible to create a dependent field based on parent field? For example  on input field can we have dependent select field?

Yes. You can do it from your JavaScript Controller input field event handler. Use component.find to locate your dependent picklist controller. Then use component.set to set the recordList of your picklist based on the input field value.

I noticed that (on the Send Offer > Edit) Rodrigo manually added in commas to the offer dollar values. Why was the formatting of the offer dollar value not carried forward from the first page (US 60,000 vs. US 60000)?

That happened because we merged the field values which were numbers with an email template body which is a String in the Apex controller. We can add the currency symbols and separators by using the Apex String.format() method as well in our server side controller.

Can we define the max, min, step and so on for Lightning input component in custom labels instead of hardcoding?

Yes. You can use custom labels. However, Lightning App Builder attributes are preferable (these are the attributes that you expose in the design file of your Lightning Component’s Bundle).
By using Lightning Components design attributes your admins will have a better user experience and will be able to set different attributes values for the same Lightning Components on different Lightning Pages/Lightning Apps. They will also be able to set the Lightning Components attributes values using the same exact Builder/UI that they use to modify Lightning pages.

Is Lightning:Input available for reference/lookup fields?

Not currently. The current beta version creates an HTML input element. This component supports HTML5 input types, including checkbox, date and datetime-local, email, file, password, search, tel, url, number, radio, toggle. The default is text.

Is it a good practice to load all the child pages as soon as the application loads and switch visibility? Or is it better to either use aura:if or create child pages dynamically only when they are needed?

It depends on the complexity of your child Lightning components and how many records they are required to interact with to render their UI and if this data depends on other child actions. In our demo, we had very simple data input forms, so we decided to load all children whenever the parent initializes, and then play around with the visibility. If you’re working with very large data sets in one of your child components, and if the data set is not dependent on the user interaction with the other children, it can be a good option to implement lazy loading to render.

How did the Send Offer button open Lightning components in a modal box?

That’s the standard UI behavior when you create an object-specific action of type Lightning component in the Lightning Experience.

Is there a reason you’re rendering all components in the DOM, and then just hiding them, as opposed to dynamically creating them based on navigation and having a single {!v.body} that is dynamic? Isn’t that easier?

That may be another good approach because dynamic creation of Lightning components gives you more flexibility and control from the JavaScript code side. It depends on the complexity of your child components and how comfortable you are with working with the dynamic approach of creating Lightning components.

What’s the benefit of using a lightning base component versus a native HTML element. For example <lighting:input vs <input>?

The benefit is that Lightning Base 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. 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.

Can’t this small app not been written inside a single parent component? (assuming we’re not using these children elsewhere). This would be a lot leaner! There is a lot of additional ‘glue’ required for children to pass session data to/from parent and each other.

It could have been written inside a single parent component but our goal was to make the different child components extensible so we could reuse them on different Lightning components. Our goal was also to logically separate the Apps markup into different children Lightning components so that it becomes easier to maintain (easier to make changes on a Team Development scenario for example).