Investigate ghost components after copying components between pages

[CharlesGrimont]

Copying components from one page to another can lead to cache-related issues where some components become “ghost” components.

Context:

• The issue appears when components are copied between pages.
• Some copied components may remain visible or referenced incorrectly.
• This seems related to stale cache/state after the copy operation.
• Reproduction should prioritize components using data sources, as this scenario has the highest impact and can lead to more severe consequences.

Investigation goals:

• Reproduce the issue when copying components between pages, especially with components bound to data sources.
• Identify which cache or editor state is not refreshed correctly.
• Determine why components can become ghost components after the copy.
• Assess the impact on copied components that reference data sources.
• Define and implement the required cache invalidation or state refresh.

Expected outcome:

• Copied components should be correctly attached to the target page.
• Data source bindings should remain valid and should not create stale or ghost references.
• No ghost components should remain after copy, refresh, preview, or page switch.
• Editor state should remain consistent after cross-page component copy.

Acceptance criteria:

• The ghost component scenario is reproduced and documented, with priority given to data-source-backed components.
• The root cause is identified.
• A fix or clear implementation plan is provided.
• No regression on same-page copy/paste or regular component duplication.
• No stale data source references remain after copying components between pages.

[CharlesGrimont]

Investigation notes

I investigated the cross-page copy path for ghost components. The issue does not look like a cache-only problem: the copy operation can create an inconsistent form model, and the stale editor/cache state then makes the inconsistency visible as ghost components.

Likely root causes

1. Copied children can receive unsafe or duplicate IDs

   In the cross-page copy flow for ion-card / layout, child IDs are generated from the original child ID:

   child.id = child.id + i + 1;
   clone.childrenRefs[i] = child.id;

   This differs from the same-page copy flow, which uses a monotonic generated ID sequence based on the cloned parent ID.

   Why this is risky:

   • if original children have adjacent timestamp-like IDs, child 0 can collide with the original child 1;
   • if the same component is copied to multiple target pages in one operation, the cloned children can receive the same IDs on each target page;
   • the editor renders formsList with trackById, so duplicate IDs can cause Angular to reuse DOM/component state incorrectly.

2. Copied children are not reattached to the cloned parent

   In the same-page copy flow, each cloned child gets:

   child.parentRef = clone.id;
   child.config.page = clone.config.page;

   In the cross-page copy flow, child.config.page is updated, but child.parentRef is not reassigned to the cloned parent.

   This can leave copied children attached to the original parent, or treated as root-level elements depending on their previous state. Since the editor displays root components with a condition equivalent to:

   item.config.page == currentPage && item.parentRef == undefined

   an orphaned child can appear as a ghost component on the target page.

3. Data-source-backed components keep the original source_id

   The datasource configuration stores a source_id that comes from the current component ID. When a component is copied to another page, the component gets a new clone.id, but the nested datasource JSON in forms_config.str is copied as-is.

   This means the cloned component can still reference the original component ID in its datasource configuration. This matches the high-impact scenario mentioned in the issue: copied datasource-backed components can keep stale references and share or reuse source state unexpectedly.

4. Possible secondary issue: formsList vs form.formulaire can diverge

   Some editor helpers, including getElementById, read from form.formulaire, while the editor rendering and many mutations use formsList. There are reorder paths that reassign formsList. If form.formulaire is not kept in sync, the cross-page copy code can clone children from stale data.

Reproduction examples

Repro 1: group/layout with children copied to another page

1. Create a form with at least two pages: Page A and Page B.
2. On Page A, add a group or layout component.
3. Add several child components inside it, for example text input, select, checkbox, or grid.
4. Use the component action to copy the group/layout to Page B.
5. Switch to Page B.
6. Observe whether children appear outside the copied group/layout, remain visible after deleting the copied parent, or appear duplicated after page switch/refresh.

Expected result: all copied children should be attached to the copied parent only.

Likely faulty result: some children are inserted on the target page with missing/wrong parentRef, so they can behave like ghost root components.

Repro 2: copy the same group/layout to multiple pages at once

1. Create a form with three pages: Page A, Page B, and Page C.
2. On Page A, create a group/layout with multiple children.
3. Use “copy to page” and select both Page B and Page C in the same operation.
4. Inspect Page B and Page C, then switch between pages or refresh the editor.

Expected result: each target page should receive an independent clone tree with unique IDs.

Likely faulty result: cloned child IDs can be reused across target pages, which can create DOM/state reuse issues because the editor tracks items by ID.

Repro 3: datasource-backed grid/select copied to another page

1. Create a datasource-backed component on Page A, for example a grid, select, or checkbox group configured from Baserow.
2. Save its datasource configuration.
3. Copy the component to Page B.
4. Open/configure the copied component, preview it, refresh the editor, or switch pages.
5. Check whether the copied component still behaves as if it were linked to the source component.

Expected result: the copied component should have its own ID and datasource configuration should reference the copied component ID.

Likely faulty result: forms_config.source_id still points to the original component ID from Page A, which can create stale datasource references.

Suggested fix direction

• Use one shared clone utility for same-page and cross-page copy.
• Generate fresh unique IDs for the whole cloned tree: parent and all descendants.
• Rebuild childrenRefs from the generated IDs.
• Always set child.parentRef = clonedParent.id for cloned children.
• Always set config.page to the target page for parent and descendants.
• When cloning datasource-backed components, parse forms_config.str and rewrite source_id to the cloned component ID.
• Ensure formsList and form.formulaire remain synchronized, or make copy helpers consistently use the same source of truth.

[CharlesGrimont]

Update after implementation:

• Fixed the component clone path so copied components receive fresh IDs, correct config.page, rebuilt childrenRefs/parentRef, and datasource forms_config.source_id references are rewritten to the cloned component ID.
• Found an additional ghost-data risk when deleting a page: the delete handler iterated over formsList with for...in while calling splice(), so consecutive components on the deleted page could be skipped and then persisted as hidden orphan components.
• Updated the page deletion flow to use a centralized cleanup helper instead of in-loop splicing. It now removes all components for the deleted page, collects descendants through childrenRefs, childrenRefsElse, and parentRef, cleans remaining child references, and syncs formsList back to form.formulaire before persisting.

Recommended manual repro checks:

1. Create a page with several consecutive components, including a group/layout with child components and at least one datasource-backed component.
2. Delete that page.
3. Save/reload the form and verify that no component from the deleted page remains in the document formulaire array.
4. Repeat after copying a group/layout to another page, then delete either the source or target page and verify copied children and datasource references are fully removed for the deleted page.

[CharlesGrimont]

The import path now sanitizes the imported structure before the new document is created and before datasource forms_config.form_id migration runs:

• removes components whose config.page references a missing page;
• removes descendants through childrenRefs, childrenRefsElse, and parentRef;
• removes orphan children whose parentRef no longer points to a remaining component;
• cleans remaining childrenRefs / childrenRefsElse so no child ref points to a removed component;
• keeps the existing datasource migration so remaining imported datasource-backed components point to the newly imported form id.

Repro example for the import case:

1. Export or craft a .c8oforms file where pages no longer contains PageOld.
2. Keep at least one entry in formulaire with config.page = "PageOld".
3. Add a nested child or referenced child through parentRef, childrenRefs, or childrenRefsElse.
4. Import the .c8oforms file from the selector/import flow.
5. Before the fix, the new form document could contain hidden ghost components or stale child refs. After the fix, those invalid imported items are removed before the form is persisted.

[github-actions]

To be tested in 2.2.0-beta112