11.3 Visualforce in Lightning Experience

11.3 Visualforce in Lightning Experience

Quick Answer: Visualforce still runs in Lightning Experience (LEX). You embed pages on Lightning record/app/home pages, tabs, and actions, improve look-and-feel with lightningStylesheets, and watch navigation/chrome differences versus Classic. Treat hybrid VF+Lightning as a bridge; migrate to LWC when you need modern composition, performance, and long-term maintainability—while remembering PDI still tests VF fundamentals.

Sections 11.1–11.2 covered markup and controllers. This section is about where VF lives in modern orgs and how exam scenarios frame Classic vs LEX vs LWC choices.

Visualforce Did Not Disappear When Lightning Arrived

Many production orgs still depend on VF for:

• Overrides of standard buttons/links not yet rebuilt in LWC
• PDF generation (renderAs="pdf")
• Dense admin tools and wizards written years ago
• Managed package UIs
• Embedded tools that already work

Salesforce’s strategic UI for new development is the Lightning Component Framework, especially LWC. Your job as a Platform Developer is dual literacy: maintain and correctly host VF, and know when not to start new work in VF.

Embedding Visualforce in Lightning Experience

Common hosting surfaces:

Record context tips

• Pages with standardController still expect an id parameter when acting on a record
• Embedded components may receive the record id through the Lightning host—design the page to read parameters or use extensions that accept standard controllers when opened from overrides
• Do not assume Classic URL shapes always match LEX hosts; test the actual entry points

Chrome attributes on apex:page often change when embedding:

• showHeader="false", sidebar="false" — reduce double headers inside LEX
• applyHtmlTag / applyBodyTag — control outer HTML when the page is framed
• Standard LEX header still wraps many tabs; avoid building a second full Classic header

lightningStylesheets

Visualforce pages historically rendered with Classic look (blue-gray pageBlocks, older fonts). In Lightning Experience, that mismatch is jarring.

lightningStylesheets="true" on <apex:page> instructs the platform to apply Lightning-styled CSS to many standard VF components so pageBlocks, tabs, and buttons better match LEX.

<apex:page standardController="Account" lightningStylesheets="true">
  <!-- standard components pick up Lightning-oriented styling in LEX -->
</apex:page>

What it does and does not do

If you ship heavy custom CSS built for Classic, audit it after enabling lightningStylesheets. Specificity wars are common.

Navigation Considerations

Classic VF often used:

• Full page redirects via PageReference
• window.top.location hacks for console/iframes
• Assumptions about sidebar, header, and URL patterns (/apex/PageName)

In Lightning Experience:

1. Iframes / containers — Embedded VF may run in a container; aggressive window.top navigation can break the Lightning shell or be blocked.
2. PageReference still works for many server-side redirects, but UX may feel like a full reload inside the LEX frame.
3. Lightning Navigation — For modern client-side patterns you would use Lightning navigation service in LWC/Aura, not classic JS hacks. Hybrid pages should minimize cross-frame gymnastics.
4. RetURL / saveURL / cancelURL parameters from Classic button overrides may not map 1:1—prefer explicit PageReference returns you control.
5. Console vs standard nav — Service Console workspace tabs add another navigation model; VF that assumes a single browser tab can misbehave.

Practical guidance for exam scenarios

• Prefer server-side PageReference navigation you can reason about over brittle DOM navigation
• When the requirement is “navigate to a record page in Lightning without full Classic chrome,” the better long-term answer is often LWC + NavigationMixin, not a new VF page with window.location
• If maintaining VF, set header/sidebar flags appropriately and test in LEX, not only Classic

Lightning Experience vs Classic Differences Relevant to VF

Security and sessions are still Salesforce sessions in both UIs, but clickjack protections, CSP, and locker rules around embedded content matter more as you mix JS. Keep VF JavaScript conservative; prefer platform components and tested remoting patterns.

Hybrid Apps: Living with Both

A hybrid approach is normal during multi-year migrations:

Lightning Record Page
├── LWC: highlight panel & related lists (modern)
├── LWC: custom path or KPI tiles
└── Visualforce embed: legacy pricing worksheet not yet rewritten

Hybrid best practices

1. Isolate legacy VF to the smallest surface that still needs it
2. Do not start parallel new features in VF on the same page if LWC can own them
3. Share Apex domain services between VF controllers and LWC Apex controllers—avoid duplicating business rules in two UI layers with divergent bugs
4. Align field-level security and sharing assumptions across both UIs
5. Document why the VF island remains (PDF, package vendor, rewrite cost) so future teams do not cargo-cult more VF

Data communication: Classic VF and LWC on the same record page do not automatically share a rich component event bus like two LWCs. They share the database and sometimes URL/record id. Design updates so each side refreshes appropriately (user refresh, platform events, or accept eventual consistency).

When to Migrate Visualforce to LWC

Migrate (or build new in LWC) when most of these are true:

Keep VF longer when

Migration pattern (conceptual)

1. Extract business logic from VF controllers into service classes used by both UIs
2. Rebuild UI as LWC with wire/imperative Apex
3. Replace button overrides and App Builder embeds
4. Retire the VF page after traffic dies
5. Keep PDF VF until you adopt an alternative document strategy

Exam Decision Mini-Scenarios

1. “New interactive component on Account record page, reusable, LEX only.” → LWC, not new VF.
2. “Existing VF page looks Classic inside LEX.” → Enable lightningStylesheets, fix chrome attributes, consider CSS cleanup—not necessarily an emergency rewrite.
3. “Need PDF of Quote.” → VF renderAs="pdf" remains a standard answer unless the scenario specifies another document product.
4. “Page hits view state limits and users live in LEX.” → Fix state/pagination and consider LWC migration for the interactive parts.
5. “Standard controller extension still required while page is VF.” → Extension patterns from 11.2 still apply inside LEX-hosted VF.

Study Checklist for UI Domain VF Topics

• Read and write basic apex:page with form, inputField, commandButton
• Choose standard vs extension vs custom controller for a scenario
• Explain view state and one mitigation (transient, pagination)
• Place VF on a Lightning page/tab conceptually
• State what lightningStylesheets does (styling, not architecture change)
• Argue LWC for new LEX UI vs VF for PDF/legacy

Bottom line: In Lightning Experience, Visualforce is an embedded citizen, not the default capital. Style it with lightningStylesheets, host it on pages/tabs/actions, navigate carefully inside the LEX shell, run hybrid architectures when needed, and migrate to LWC when modern composition and longevity matter—while still mastering VF for the User Interface portion of Platform Developer I.