One misnamed method in your Salesforce Aura Component can silently trigger an infinite loop. No obvious error, no red flag, just a Lightning page that stalls and keeps firing the same function until your browser gives up.
For developers maintaining Aura-based orgs in 2026, this is no theoretical risk but it is a genuine debugging nightmare that can cost hours of valuable development time. Despite Salesforce’s shift toward Lightning Web Components, the Aura Component framework still powers thousands of active enterprise orgs.
Legacy implementations built on Aura are still being maintained, extended, and now increasingly integrated with Agentforce — making it more important than ever to get the fundamentals right, starting with how you name your methods.
In this guide, you will learn exactly what causes the method naming conflict, how to fix it with safe naming conventions, how LWC handles this differently, and what new risks Agentforce integrations introduce in 2026.
Salesforce Aura Components: The 3 Core Elements
Salesforce launched Aura back in 2014 as its first modern framework for creating reusable pieces of Lightning Experience UI. Developers no longer needed to code entire pages from nothing. They could mix and match ready-made components instead, speeding up how teams tailor Salesforce to fit specific workflows.
Every Aura component is built on three core elements:
- Aura Component Markup — the HTML-like structure that defines what the component looks like.
- Client-Side Controller — a JavaScript controller that handles user interactions and business logic on the front end.
- Server-Side Apex Controller — an Apex class that queries and processes data from the Salesforce database.
That JavaScript layer talks directly to the Apex side. It sends requests for data, and Apex sends responses.
In 2026, new projects will all use Lightning Web Components now. But Aura is far from dead. Thousands of enterprise orgs still run on Aura-heavy implementations, and many teams are actively maintaining or extending them rather than rebuilding from scratch.
This layered architecture works beautifully — until method names collide across the JavaScript and Apex layers.
How to Call Apex Method in Aura Component
Before the naming trap makes sense, it helps to see the standard flow first — how an Aura component actually calls an Apex method under normal conditions.
That request goes through $A.enqueueAction. Here’s the step-by-step:
- JavaScript grabs the Apex method using component.get(“c.methodName”)
- Creates an “action” variable that points to your @AuraEnabled Apex method
- Attaches a callback function to process whatever Apex sends back
- Queues it: $A.enqueueAction(actionVar)
Salesforce runs it server-side, sends data back. Done.
Working example:
Apex Controller:
Aura Component Markup:
JavaScript Client-Side Controller:
Notice the naming here. The JavaScript method is called getStringsFunction. The action variable that points to the Apex method is called getStringsAction. And the Apex method itself is getStrings. Three distinct names, three distinct layers — no overlap, no confusion.
This separation is deliberate. The queued action list in Aura resolves names at runtime, and it needs to be able to tell the difference between a JS method and an Apex action variable. When those names are the same, that is where things break down — and break down badly.
Salesforce Aura Component Best Practices: The Method Naming Trap
Now that you have seen the correct flow, here is where developers consistently go wrong.
After writing three getAccountData, getContactData, getOpportunityData methods, you get tired of thinking up new names. Apex method is getStrings. Why not make the JS method getStrings too? Makes sense, right? It feels clean. It feels logical.
This looks clean to humans. Aura sees chaos.
Here is what the broken version looks like:
Apex Controller:
Aura Component Markup:
JavaScript Client-Side Controller:
Three things share the same name here — the JS method, the action variable, and the Apex method. To a human reading the code, it looks fine. To Aura’s queued action list, it is chaos.
Here is what actually happens at runtime:
- The page loads and triggers getStrings
- Aura queues getStrings as an action
- Instead of resolving it to the Apex method, the queued action list picks up the JS method name
- The JS method fires again — and immediately re-queues getStrings
- That re-queue fires the JS method again
- And again. And again.
Console stays quiet. No red errors. Page just… stops. Browser fans spin up. Network tab? Same getStrings action over and over and over. 47 calls in 3 seconds. You pull up the code later thinking ‘this SHOULD work.’ Everything looks textbook perfect. That’s what drives you nuts.
Unlike modern JavaScript frameworks that resolve variables by reference, Aura’s queue system resolves by name. It sees getStrings and runs the JS method. Every single time.
Salesforce Aura Component Naming Rules and the Safe Fix
The fix is simpler than the bug. You just need three distinct names across three distinct layers — and a consistent convention to make sure they never collide again.
Here is the rule:
- JS Controller Method → suffix with Function (or prefix with handle, e.g. handleLoadStrings)
- Apex Action Variable → suffix with Action (or prefix with call, e.g. callGetStrings)
- Apex Method → keep as is, descriptive and clear
The specific suffix or prefix matters less than applying it consistently across your entire codebase.
Put that into practice and the same code that was broken before now looks like this:
Apex Controller:
Aura Component Markup:
JavaScript Client-Side Controller:
Same logic, same Apex method, same result — but now Aura’s queue system has no ambiguity. getStringsFunction is clearly a JS method. getStringsAction is clearly the variable pointing to Apex. Nothing overlaps, nothing loops.
Here is a quick reference table to apply this across your codebase:
Beyond the suffix convention, a few broader naming rules worth keeping in mind:
- Component bundle names must begin with a lowercase letter — alphanumeric and camelCase only, no underscores
- Apex class names begin with uppercase — PascalCase with a descriptive suffix
- camelCase for all JS identifiers across the client-side controller
- Keep names descriptive enough that their layer is obvious at a glance
Consistent naming across your Apex and JavaScript layers does more than prevent infinite loops. It makes your codebase readable for the next developer who picks it up — and in large Salesforce orgs, that matters as much as the code working correctly.
Aura vs LWC — Does This Problem Exist in Lightning Web Components?
Short answer: not in the same way. But that does not mean LWC is immune to recursion problems entirely.
The root cause of the Aura infinite loop is architectural. In Aura, $A.enqueueAction resolves method names at runtime by scanning the controller object. Same name in two places — Aura picks the wrong one.
LWC works differently. Apex methods are imported as JavaScript modules at the top of the file:
That import creates a local alias. Your component refers to the alias, not the original method name. No shared namespace, no queue system, no collision risk.
Here is a safe imperative Apex call in LWC:
handleLoadStrings and fetchStringData — two distinct identifiers, separated at import level. No runtime ambiguity.
That said, LWC has its own reactive pitfall. If a @wire result mutates the property it depends on, you get a re-render loop:
Same discipline applies — keep reactive properties and wire dependencies clearly separated. The framework changes. The principle does not.
Agentforce Aura Component Integration — 2026 Naming Pitfalls
Spring ’26 expands @AuraEnabled Apex exposure as Agentforce agent actions. That is a powerful capability — but it introduces a new layer of risk for orgs that have not cleaned up their naming conventions.
If an agent action calls the same conflicted Apex method that is also wired into an Aura component, you risk compounded recursion — agent calls triggering the same conflicted Apex method alongside a front-end loop simultaneously. Two problems, one bad method name.
Harder to reproduce. Harder to debug. Much harder to explain to a stakeholder.
The fix is the same one covered earlier — distinct names across every layer before you expose any method to Agentforce. Think of clean naming as a prerequisite for Agentforce-ready development, not an afterthought.
If you spot a loop, open the developer console network tab. Repeated calls to the same action firing in rapid succession are the tell. Catch it in the sandbox before it reaches production.
Explore how TechForce approaches Salesforce Agentforce integrations built on a clean, conflict-free architecture.
Salesforce Aura Component Performance Checklist
Before you ship any Aura component — or expose it to Agentforce — run through this quickly:
Naming
- JS controller methods suffixed with Function or prefixed with handle
- Apex action variables suffixed with Action or prefixed with call
- No shared identifiers across JS and Apex layers
- aura:method names distinct from all Apex method names — especially in parent-child component relationships
- Component bundle names lowercase, camelCase, no underscores
Code Quality
- Apex controller classes PascalCase with Controller suffix e.g. ContactController — makes it immediately clear in JS which class component.get(“c.someMethod”) is hitting
- Non-controller Apex classes PascalCase with descriptive suffix e.g. ContactService
- All JS identifiers camelCase throughout the client-side controller
- @AuraEnabled methods named clearly before Agentforce exposure
Testing
- Network tab checked for repeated action calls before deployment
- Naming collision test run in sandbox before production
- Parent-child component method calls verified for naming conflicts
Conclusion
One shared method name across your JavaScript and Apex layers. That is all it takes to stall a Lightning page with no error, no warning, nothing.
The fix is straightforward — distinct names, consistent conventions, clean separation across every layer. What has changed in 2026 is the stakes. Agentforce now calls @AuraEnabled methods directly, meaning a naming conflict can trigger something far harder to untangle than a front-end loop.
Clean naming is not a nice-to-have. It is the foundation everything else builds on.
Naming inconsistencies accumulate quietly in orgs that have grown over several years. Our Salesforce Health Check can catch exactly that.
FAQs
What is a Salesforce Aura Component?
Salesforce Aura Components are reusable UI blocks for Lightning Experience. Built on markup + JavaScript controller + Apex controller. Still powers thousands of enterprise orgs in 2026.
What causes infinite loops in Aura components?
JS method shares name with Apex action variable. Aura’s queue picks JS method instead of Apex call. Method re-fires endlessly—no console error, just browser stall.
Aura method vs LWC wire adapter?
Aura: $A.enqueueAction resolves names at runtime = collision risk. LWC: Imports Apex as module = isolated names. @wire binds data reactively, no name conflicts.
How do I name Aura actions safely?
JS methods: Function suffix or handle prefix. Action vars: Action suffix or call prefix. Apex methods stay descriptive. Consistency > specific pattern.
Migrate Aura to LWC in 2026?
Replace $A.enqueueAction with @salesforce/apex imports. Use @wire for reactive data. Test reactive property loops. Clean Aura naming = smoother transition.
