Display Map with List Value in a Lightning Component #Salesforce

🗺️ Displaying a Map with List Values in a Lightning Component

When working with complex data structures in Salesforce, using a Map with a List as its value is common in Apex. But displaying this structure in a Lightning Component (Aura or LWC) requires a few tricks. This blog walks through how to pass and render a Map<String, List<Object>> in a user-friendly way.

---

📦 Use Case

You're retrieving a list of Contacts grouped by Account Name, like:

Map<String, List<Contact>> contactsByAccount = new Map<String, List<Contact>>();

Now, you want to display each account with its related contacts in a Lightning component.

---

⚙️ Apex Controller

@AuraEnabled(cacheable=true)
public static Map<String, List<Contact>> getContactsByAccount() {
    Map<String, List<Contact>> result = new Map<String, List<Contact>>();
    for (Account acc : [SELECT Id, Name, (SELECT Id, Name, Email FROM Contacts) FROM Account LIMIT 10]) {
        result.put(acc.Name, acc.Contacts);
    }
    return result;
}

---

🧩 Aura Component Example

<aura:component controller="YourApexClass">
    <aura:attribute name="contactsMap" type="Object"/>
    
    <aura:handler name="init" value="{!this}" action="{!c.doInit}"/>

    <aura:iteration items="{!v.contactsMap}" var="key">
        <p><strong>{!key}</strong></p>
        <aura:iteration items="{!v.contactsMap[key]}" var="con">
            <p>- {!con.Name} ({!con.Email})</p>
        </aura:iteration>
    </aura:iteration>
</aura:component>

---

⚡ Client-side Controller (JS)

doInit: function(component, event, helper) {
    var action = component.get("c.getContactsByAccount");
    action.setCallback(this, function(response) {
        if (response.getState() === "SUCCESS") {
            component.set("v.contactsMap", response.getReturnValue());
        }
    });
    $A.enqueueAction(action);
}

---

✅ Best Practices

• Use @AuraEnabled(cacheable=true) for better performance.

• Always check for null values in JS to avoid runtime errors.

• For LWC, transform the map into an array format using Apex before returning.

---

💬 Final Thoughts

Using a Map<String, List<Object>> structure allows powerful grouping in Apex. With the right approach, rendering it in the Lightning UI is clean and intuitive.

🏋️‍♂️ Boosting Query Performance with Skinny Tables in Salesforce

Salesforce is known for its powerful platform, but performance can take a hit when working with large datasets. This is where Skinny Tables come into play. They’re a Salesforce-supported performance optimization feature that helps speed up reports, dashboards, and queries—especially in data-heavy orgs.

🔍 What is a Skinny Table?

A Skinny Table is a custom, read-only table maintained by Salesforce. It contains a subset of fields from a standard or custom object—indexed and denormalized to avoid joins and speed up queries.

• Managed internally by Salesforce

• Updated near real-time with the source object

• Limited to 100 fields per table

• Fields must be of certain data types (e.g., no long text, rich text, etc.)

---

📘 Use Case: Slow Report on Opportunities

Problem: A report filtering on multiple Opportunity fields (e.g., StageName, Amount, OwnerId, Custom_Field__c) is running slow due to large volume (~10M rows) and non-indexed filters.

Solution: Create a skinny table with just the critical fields used in the report filter and display.

Skinny Table: Opportunity_Skinny
Fields:
- Id
- StageName
- Amount
- OwnerId
- Custom_Field__c
- CloseDate

Result: Queries now pull from a smaller, indexed table with no joins—improving performance drastically.

---

🛠 How to Use Skinny Tables

You cannot create skinny tables via UI or Apex. You must raise a Salesforce Support case with:

• Object name

• Fields to include

• Use case (e.g., performance bottleneck on reporting or SOQL)

---

✅ Best Practices

1. Use only when needed
   Ideal for high-volume objects and slow queries. Avoid overuse—each skinny table adds overhead to SFDC's backend.

2. Pick frequently used fields
   Focus on filter and output fields. Avoid large text, formula, or lookup fields.

3. Test before and after
   Benchmark SOQL or report runtime to validate the improvement.

4. Be aware of limitations

   • Doesn’t support sandbox refresh automatically

   • No support for all field types

   • Changes require support ticket

5. Combine with other optimizations
   Skinny tables work well alongside custom indexes and selective queries.

---

✅ Steps to Enable:

1. Open a Salesforce Support Case

   • Go to: help.salesforce.com

   • Click "Create a Case"

2. Case Details to Provide:

   • Subject: Request to create a skinny table

   • Reason: Performance optimization

   • Details:

     • API name of the object (e.g., Opportunity)

     • List of fields to include (up to 100)

     • Example SOQL query or report that’s slow

     • Sandbox or Production org

     • Justification: Performance issues, query time, or user impact

3. Salesforce Support Review:

   • They’ll validate field compatibility

   • Implement the skinny table on backend

   • Provide confirmation once it’s live

4. Test & Monitor:

• Validate performance improvements

• Monitor regularly—especially after schema changes

---

🧠 Pro Tip

You can use Query Plan Tool in Developer Console to identify whether a query is selective—and whether skinny tables or custom indexes could help.

---

📌 Final Thoughts

Skinny tables are a powerful lever for performance, especially in data-intensive orgs. Use them strategically, monitor their impact, and pair them with indexing and query optimization for maximum benefit.