What problem does this address?

There is no createEntityRecord action in @wordpress/core-data, which blocks a local-first UX. The only available path is saveEntityRecord, which writes to the database immediately and forces cleanup if the user cancels.

A createEntityRecord action would allow creating a local-only entity record in the store, editing it, and saving only when the user confirms.

For instance, DataViews/DataForm is well-suited for list + form flows, but new-item creation cannot be done without persisting to the database. This prevents:

• Draft-first creation flows (create -> edit -> save)
• Canceling a create flow without cleanup
• Wizard-like experiences for new items

Demo plugin

I prepared a small plugin that demonstrates the gap:

• Admin page with a Books list rendered via DataViews
• Book form rendered via DataForm
• “New book (in-memory)” action that would use createEntityRecord
• Current workaround: saveEntityRecord (draft saved immediately)

This means that the user must save data to the database before updating the entity.

Expected behavior

• createEntityRecord creates a local-only draft record in the store without persisting to the database.
• The draft can be updated via editEntityRecord.
• saveEntityRecord (or saveEditedEntityRecord) persists the draft and returns the real ID from WordPress.

Ideal experience

A local-only draft should be possible via createEntityRecord, and then updated with editEntityRecord until the user explicitly saves. The draft ID is temporary; WordPress assigns the real ID on save.

const { dispatch } = wp.data;

const draft = dispatch( 'core' ).createEntityRecord(
  'postType',
  'book',
  { title: 'New book', status: 'draft', meta: { book_author: '' } }
);

// Update the draft locally.
dispatch( 'core' ).editEntityRecord( 'postType', 'book', draft.id, {
  title: 'Updated title',
  meta: { book_author: 'New author' },
} );

// Persist only when the user confirms.
await dispatch( 'core' ).saveEntityRecord( 'postType', 'book', draft );