SfSkills Domains Docs GitHub

Home / lwc / lwc-lightning-record-forms

lwc-lightning-record-forms

lightning-record-form vs record-edit-form vs uiRecordApi for record create/edit in LWC. Triggers: lightning-record-form, record-edit-form, uiRecordApi form. NOT for fully custom forms — use lwc/lwc-forms-and-validation.

Open the skill folder on GitHub

LWC Lightning Record Forms

Lightning Data Service ships three form base components that remove the most common reasons developers hand-write forms: field-level security enforcement, page-layout awareness, automatic validation, and managed save/error UI. They are lightning-record-form (the all-in-one), lightning-record-edit-form (create/edit with custom layout), and lightning-record-view-form (read-only with custom layout).

The decision is mostly about how much layout control you need. lightning-record-form is one tag, takes an object + optional record Id + a layout-type, and renders the entire form including mode toggle, save/cancel buttons, spinner, and inline errors. The two -edit-form and -view-form variants give you back the template — you place lightning-input-field / lightning-output-field yourself and own the buttons. Both still leverage LDS for caching, FLS, and validation.

The mistakes follow a predictable pattern. Engineers reach for a hand-rolled form with @wire(getRecord) and manual DML the moment they need a single CSS tweak, abandoning every benefit of LDS. Or they try to mix lightning-record-edit-form with custom Apex @AuraEnabled saves, fighting the framework. Or they forget that lightning-input-field requires field-name to be a value imported via @salesforce/schema/Object.Field, not a string literal — and the form silently renders nothing.

  1. Choose the smallest component that works. Start with

    lightning-record-form. Move to -edit-form or -view-form only when you need a custom layout, custom buttons, or conditional fields. Never start with hand-rolled.

  2. Import field references via @salesforce/schema. This

    is what enables compile-time validation, FLS enforcement, and safe refactoring. String-literal field names in field-name are accepted but lose all of the above.

  3. Pick the layout-type deliberately. Compact mirrors the

    compact layout (Salesforce-managed, admin-editable). Full mirrors the page layout. A fields=[...] array is fully programmatic — use this when the form's contents must not shift when an admin edits the layout.

  4. Wire onsuccess, onsubmit, and onerror. onsubmit

    fires before save, lets you mutate event.detail.fields for conditional defaults; onsuccess fires after, lets you fire a toast or navigate. Without onerror, validation errors still show inline (LDS handles it) but you cannot react programmatically.

  5. **Set density="comfy" | "compact" | "auto" to match the host

    surface.** Default auto adapts to the SLDS density flag set on the user record — overriding only makes sense when the form is on a tightly-scoped page (a modal) where you know which layout you want.

  6. Test by simulating LDS in jest. Use

    @salesforce/sfdx-lwc-jest mocks for getRecord / createRecord / updateRecord. Do not unit-test the form's internal save logic — that is platform code.

When To Reach For Custom (Skip This Skill)

If you need a wizard with multiple steps, a custom save endpoint that does cross-object orchestration, or a UI tightly coupled to non-Salesforce data, do not start with lightning-record-edit-form. Build the form with lightning-input components and call your Apex method directly. The LDS form components are for the case where Salesforce is the source of truth for one record at a time.

What This Skill Does Not Cover

TopicSee instead
Fully custom forms with uiRecordApilwc/lwc-custom-form-with-uiRecordApi
Custom lookup fields inside a formlwc/lwc-custom-lookup
Datatable inline editlwc/lwc-datatable-advanced
Aura lightning:recordEditFormAura is deprecated for new work

Package files