[object Object]

What’s New

At TDX 2026, Salesforce announced Multi-framework support — developers can build native Salesforce apps starting in React. Platform-grade authentication, security, and governance apply without bolt-on work. The runtime is an extension of Lightning Web Runtime (LWR) that compiles React components down to LWR-compatible bundles, so the same packaging, deployment, and source tracking pipelines apply. Project layout looks familiar:

force-app/
└── main/
    └── default/
        └── react/
            └── components/
                └── opportunityDashboard/
                    ├── opportunityDashboard.tsx
                    ├── opportunityDashboard.module.css
                    └── __tests__/
                        └── opportunityDashboard.test.tsx

sf project deploy start deploys React components alongside LWC and Apex without separate tooling. The sf CLI gained sf react:component:create --name foo --type page for scaffolding.

Why React

Most web developers know React. LWC is Salesforce-native but a skills silo. Multi-framework drops the ‘learn LWC first’ barrier. Salesforce gets a larger developer pool; developers get their preferred framework. The hiring math is straightforward: roughly 4 million React developers globally versus an estimated 80,000 active LWC developers. Onboarding a senior React engineer to a Salesforce project previously required 3–6 weeks of LWC ramp-up; with multi-framework, the ramp drops to 1–2 weeks focused on platform concepts (governor limits, FLS, sharing rules) rather than framework syntax.

What’s Preserved

Security model, auth flows, governor limits, Trust Layer — all apply to React apps just as they do to LWC. The React you write is sandboxed and governed like any first-class Salesforce code. Specifically:

  • FLS enforcement: useUiApi() hook returns only fields the running user can read; write attempts to inaccessible fields throw before the API call
  • Sharing: SOQL queries fired through the React data hooks respect sharing rules identically to LWC @wire
  • Governor limits: Same per-transaction limits apply; React doesn’t get a “framework loophole”
  • Trust Layer: AI calls from React components route through the same masking and audit pipeline
  • CSP: React components run under the Lightning Locker Service successor (Lightning Web Security) with the same script-src restrictions

Example data hook:

import { useRecord } from '@salesforce/react';

function OpportunityCard({ recordId }: { recordId: string }) {
  const { data, error, loading } = useRecord({
    recordId,
    fields: ['Opportunity.Name', 'Opportunity.Amount', 'Opportunity.StageName']
  });

  if (loading) return <SkeletonCard />;
  if (error) return <ErrorBanner error={error} />;
  return <OpportunityView data={data} />;
}

When to Use

Greenfield apps where team React fluency is strong. Porting external React apps into Salesforce contexts. Continue using LWC for deep platform integration (record pages, utility bar, AppExchange components). The decision matrix:

ScenarioUse
Custom internal app, React-fluent teamReact
Porting existing React SPA into SalesforceReact
Standard record page componentLWC
Utility bar / quick actionLWC
AppExchange-distributed componentLWC
Experience Cloud site themeEither; React if customization is heavy
Highly stateful dashboard with chartingReact

What Changed in 2026

Pre-TDX 2026, the answer to “can I build Salesforce apps in React” was “yes, but you’ll lose platform integration.” Post-TDX, it’s “yes, with full platform integration, on the same deployment pipeline as LWC.” The shift recognizes a market reality: developers vote with their feet, and forcing LWC on every new project capped the addressable developer pool.

Common Failure Modes

Bundle size bloat. React + a typical component library can balloon a Salesforce page to 800KB+ of JavaScript, blowing past Lightning page performance budgets. Use the new sf react:bundle:analyze command to identify dependencies and tree-shake aggressively. Second failure: assuming React’s component lifecycle maps 1:1 to LWC’s. useEffect runs after render; LWC’s connectedCallback runs before. Race conditions on data loading appear where LWC didn’t have them. Third: importing npm packages that violate Lightning Web Security (LWS) — the build will succeed but the runtime will block the script.

What to do this week

Identify one greenfield app on your roadmap that suits React. Spin up a scratch org, scaffold a starter component with sf react:component:create, deploy, and verify FLS enforcement against a non-admin profile. The end-to-end test confirms the platform contract before you commit to the framework choice.

[object Object]
Share