# 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.

- Skill: `pranavnagrecha/lwc-lightning-record-forms` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds add pranavnagrecha/lwc-lightning-record-forms`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pranavnagrecha/lwc-lightning-record-forms/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: PranavNagrecha (https://skillmd.com/u/pranavnagrecha)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/pranavnagrecha/lwc-lightning-record-forms

---


# 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.

## Recommended Workflow

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

| Topic | See instead |
|---|---|
| Fully custom forms with `uiRecordApi` | `lwc/lwc-custom-form-with-uiRecordApi` |
| Custom lookup fields inside a form | `lwc/lwc-custom-lookup` |
| Datatable inline edit | `lwc/lwc-datatable-advanced` |
| Aura `lightning:recordEditForm` | Aura is deprecated for new work |