Lightning Aura Components Developer Guide

Introducing Aura Components
Quick Start
Creating Components
Using Components
Communicating with Events
Communicating Across the DOM with Lightning Message Service
Creating Apps
Styling Apps
Developing Secure Code
Using JavaScript
Working with Salesforce Data
Lightning Data Service
Using Apex
Creating Server-Side Logic with Controllers
Apex Server-Side Controller Overview
AuraEnabled Annotation
Creating an Apex Server-Side Controller
Using Apex to Work with Salesforce Records
Granting User Access for Apex Classes
Securing Data in Apex Controllers
Calling a Server-Side Action
Queuing of Server-Side Actions
Batching of Server-side Actions
Boxcar Grouping and Optimization
Manage Synchronous Action Dependencies
Disable Dynamic Boxcar Optimization for Aura Actions
Foreground and Background Actions
Storable Actions
Abortable Actions
Action Limits and Considerations
Testing Your Apex Code
Making API Calls from Apex
Make Long-Running Callouts with Continuations
Creating Components in Apex
Testing Components
Debugging
Performance
Reference
PDF

Batching of Server-side Actions

Multiple queued actions are batched together into a group, and then sent to the server in a single request (XHR) to minimize network round trips. The batching of actions is also known as boxcar’ing, similar to a train that couples boxcars together.

The framework doesn’t guarantee any specific order of execution of actions or action callbacks. XHR responses can return in a different order than the order in which the XHR requests were sent due to server processing time. If two actions must execute sequentially, the component must orchestrate the ordering. For example, the component can enqueue the first action. Then, in the first action’s callback, the component can enqueue the second, dependent action.

Important

All actions sent in the same boxcar are processed in one transaction. If you see an error for “uncommitted work pending”, it’s possible that a later action can’t be completed due to uncommitted work for an earlier action in the same transaction. For example, if the first action updates a record, an Apex callout in a second action can’t be completed due to the uncommitted work from the first action.

The server returns the XHR response to the client when all actions have been processed on the server. If a long-running action is in the boxcar, the XHR response is held until that long-running action completes.

Set a long-running action as a background action to send that action separately from foreground actions. The separate transmission ensures that the background action doesn’t impact the response time of the foreground actions. The motivation for background actions is to isolate long-running actions into a separate request to avoid slowing the response for foreground actions. See Foreground and Background Actions for additional details.

Note