0

I have some Apex calls I would like to run in the background from a Lightning Web Component. Looking into the "correct" way to do so, I haven't found much concrete information. I see Aura had Foreground and Background Actions, which meant you could call action.setBackground();. However, Lightning Web Components seem to be lacking in feature parity here. The corresponding documentation in the Lightning Components Developer’s Guide actually just describes how it works in Aura, as far as I can tell. It also mentions at the very bottom:

To mark a server-side action as a background action in Java, use the @BackgroundAction annotation at the method level on the controller.

But A) it's Apex, not Java, and B) that annotation does not exist.

What are my options? It seems like setTimeout(myApex, 0) might work, but is a bit hacky and recommended against. I'm also not sure if those calls will still block the UI or not. Are there any supported alternatives? Is that the "canonical" approach?

Improve this question

2 Answers 2

Reset to default
2

Apex calls don't block the UI. Instead of setTimeout, which is indeed not recommended, you can typically just wait a render cycle using:

async someMethod() {
  await Promise.resolve(); // update UI
  let result = await someApexMethod({params});
}

Also, read this answer.

Improve this answer
7
  • 1
    @AdrianLarson Ever since Aura, traditional UI blocks have to be a conscious choice (e.g. using XMLHttpRequest incorrectly). That said, too many calls certainly make the initial load seem slower. The linked answer addresses how the frameworks differently with wire/imperative calls. For really heavy components, a more advanced design, like an orchestrator design, has been recommended by some people (and I agree, honestly).
    – sfdcfox
    Nov 18, 2022 at 19:17
  • 1
    @AdrianLarson Orchestrator (or, if you prefer, Conductor) is when you have a single component control all requests to the server; the component accepts incoming requests from all components that use it, prioritizes them, and calls them in small batches to purposefully break the boxcar effect. Done right, it can dramatically improve the perceived loading time of the framework. Not surprised you haven't heard of it, it's used by, I think, MattLacey, and myself, it's rather unique. I might have to write a blog post on it.
    – sfdcfox
    Nov 18, 2022 at 19:36
  • 1
    We have this pattern implemented in our schedule view component these days, calling it a request orchestrator. This is the same component shown, before adding the orchestrator, in this Q&A.
    – Phil W
    Nov 18, 2022 at 19:39
  • 1
    BTW, it isn't just perceived performance improvement (if the network has reasonable latency) since you can run more requests in parallel over the whole set of requests. Boxcarred requests run sequentially on the server. Of course, boxcarring reduces the number of separate requests across the network, and can win out on a poor connection.
    – Phil W
    Nov 18, 2022 at 19:42
  • 1
    @PhilW Thanks for the addendum. I know the "in close proximity" thing vexed me at one point, glad to hear it's been apparently ironed out. In fact, I think I've noticed that in my own product I've been working on.
    – sfdcfox
    Nov 18, 2022 at 19:44
1

All wire and imperative calls to Apex are naturally "background processing", not blocking the UI thread, as stated by @sfdcfox.

There is literally nothing you need to do to enable this. If you want to continually perform "background processing", simply chain the imperative apex from the promise handlers for the previous call. If you want to have a delay between calls then you need to use the setTimeout alternative as covered by Foxy.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .