How to Create Map of Accountid and List of Contacts

Here's an example code snippet in Apex that retrieves a map of account IDs and their corresponding list of contacts:

Map<Id, List<Contact>> accountContactsMap = new Map<Id, List<Contact>>();
List<Contact> allContacts = [SELECT Id, AccountId FROM Contact];

for(Contact c : allContacts){   
    if(accountContactsMap.containsKey(c.AccountId)){
       accountContactsMap.get(c.AccountId).add(c);
    } 

    else{
        accountContactsMap.put(c.AccountId, new List<Contact>{c});
    }
}

In this example, we first create a Map that will store Account IDs as keys and lists of associated Contact records as values.

We then query all Contact records and iterate through them using a for loop. For each Contact, we check if the AccountID is already a key in the accountContactsMap using the containsKey() function. If it is, we add the Contact to the existing list of contacts for that account using the add() function. If it's not, we create a new list containing the current Contact and add it to the map using the put() function.

After the loop completes, the accountContactsMap will contain all Account IDs as keys and lists of their associated Contact records as values.

Difference Between Wire Method And Imperative Method in LWC

In Lightning Web Components (LWC), the wire method and imperative method are two different ways of retrieving data from an Apex controller or an external data source.

The wire method is a reactive approach that retrieves data declaratively. It uses the @wire decorator to declare the properties that the component needs and the Apex method to call to get the data. When the component loads or the properties change, the wire method automatically updates the component with the new data.

The imperative method is an imperative approach that retrieves data programmatically. It uses the import statement to import the Apex method and then calls it manually using JavaScript code. This approach is useful when you need to retrieve data based on user input or component events.

Overall, the choice between the wire method and the imperative method depends on the specific use case and requirements of the component. The wire method is more suitable for simple data retrieval scenarios, while the imperative method offers more flexibility for complex data retrieval and update scenarios.

How to Automatically Refresh DataTable In LWC

To automatically refresh a Lightning web component (LWC) Datatable in Salesforce, you can use the refreshApex function from the Apex class to refresh the data and re-render the component.

The refreshApex method in LWC can only be used with the @wire decorator to retrieve data from an Apex controller.

Here's an example of how to use refreshApex to automatically refresh a Datatable every 10 seconds:

import { LightningElement, wire } from 'lwc';
import { refreshApex } from '@salesforce/apex';
import getAccountList from '@salesforce/apex/

               AccountController.getAccountList';

export default class AccountTable extends 

                                LightningElement {
    accounts;
    error;
    refreshTable;

    @wire(getAccountList)
    wiredAccountList(result) {
        this.refreshTable = result;
        if (result.data) {
            this.accounts = result.data;
            this.error = undefined;
        } else if (result.error) {
            this.error = result.error;
            this.accounts = undefined;
        }
    }
    connectedCallback() {
        setInterval(() => {
            refreshApex(this.refreshTable);
        }, 10000);//Refresh every 10 seconds
    }
}

In this example, the connectedCallback lifecycle hook is used to set up an interval that calls the refreshApex function every 10 seconds. The refreshApex function takes the result property of the @wire adapter as an argument, which causes the adapter to fetch the latest data from the server and re-render the component.

Note that when refreshApex is called, it re-fetches the data from the server and updates the cache. If there is any change in the data, the UI will be updated with the new values. If there is no change, the UI will remain the same.

Switch Statement in Apex Salesforce

In Apex, a switch statement is a control flow statement that evaluates an expression and executes code based on the value of the expression. The switch statement is used when you have multiple conditions to check and execute different blocks of code based on those conditions.

The syntax of a switch statement in Apex is as follows:

switch on (expression) {
    when value1 {
        // code block to execute when 

expression equals value1
    }
    when value2 {
        // code block to execute when 

expression equals value2
    }
   
    when else {
        // code block to execute when 

expression does not equal any of the

        specified values
    }
}

In this syntax, expression is the expression to evaluate, and value1, value2, and so on are the values to compare the expression with. You can specify any number of when clauses, each with a different value to compare the expression with.

The when else clause is optional and specifies a default code block to execute when the expression does not equal any of the specified values.

Here is an example of a switch statement in Apex:

String dayOfWeek = 'Monday';
switch on (dayOfWeek) {
    when 'Monday' {
        System.debug('Today is Monday');
    }
    when 'Tuesday' {
        System.debug('Today is Tuesday');
    }
    when 'Wednesday' {
        System.debug('Today is Wednesday');
    }
    when 'Thursday' {
        System.debug('Today is Thursday');
    }
    when 'Friday' {
        System.debug('Today is Friday');
    }
    when else {
        System.debug('Today is a weekend day');
    }
}

In this example, the switch statement evaluates the dayOfWeek variable and executes the code block for the matching when clause. If the dayOfWeek variable does not match any of the specified values, the code block for the when else clause is executed.

Difference Between Custom Settings and Custom Metadata

Here is list of Difference Between Custom Settings and Custom Metadata Types

1. Custom settings enable you to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. Custom metadata are like custom setting but records in custom metadata type considered as metadata rather than data. These are typically used to define application configurations that need to be migrated from one environment to another, or packaged and installed.
2. There are 2 types of custom setting List and Hierarchy Custom setting. There are no such types in custom metadata. Custom metadata does not support Hierarchy type of data based on user profile or specific user.
3. You can control the visibility of custom setting by specifying it as public or protected. If custom setting is marked as protected, the subscriber organization will not be able to access the custom setting. If it is marked as public, then subscriber org can also access it. You can control the visibility of Custom Metadata Types by specifying it as public or protected. If it is marked as public type, then anyone can see it. If it is marked as protected type, in the installed managed package subscriber organization, only Apex code in that managed package can use it.
4. Custom settings do not support relationship fields. You can create lookups between Custom Metadata objects.
5. You can access custom setting data using instance methods and can avoid SOQL queries to database. With custom metadata types, you can issue unlimited Salesforce Object Query Language (SOQL) queries for each Apex transaction.
6. Custom metadata type are visible in test class without “SeeAllData” annotation but custom setting data is not visible.
7. Custom metadata records are deployable and packageable. But we can not deploy custom setting data.