Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
We are starting to develop a number of Lightning Components and we are struggling because of lack of well-established design patterns:
Where does global constant go and how they can be shared across multiple Lightning Components?
Can the helper contains member properties too or just function?
What are the benefit of using aura:if over dynamic component creation?
Should one use SLDS on native html items for grids or lightning:layout?
Have a look at this blog post from Christophe Coenraets: Modularizing Code in Lightning Components - he also describes how to share code using JavaScript libraries
Declaring member properties is not recommended, but you can use an expando on the component reference like component.isInitialized = true - this approach lets you store values for the usage in the helper only - you don't need to declare an and therefore you can't use the variable in markup. However, best practice would be attributes with access private declared in the markup.
<aura:if> can be invoked through data binding without additional code - but instantiating and managing you component creation by yourself is fine as well but more individual work to do.
Best practice: whenever possible use Base Lightning Components from the lightning-namespace. But: <lightning:layout> <lightning:layoutItem> creates a lot of nesting div-container in the rendered DOM which have influence on the initial render performance. If you have to render a lot of items initially, this could take dramatically more time as using plain HTML (which are, just say, also Lightning Components without a namespace ;-) - I would say this is a special use case we run into, so give the <lightning:layout> a try - and so you don't have to fiddle around with appr. 20 different slds-style-tags by yourself :-)
