# Import "Create New Field" — Issues Tracker

Side issues found while building the import **create-new-field** feature.
PR: [feat(Import): create new fields via updateSchema #5476](https://github.com/wix-private/cairo/pull/5476) · JIRA: CAIRO-4230

**Status:** `open` / `in progress` / `done` / `dismiss` · **Severity:** Major / Minor / Nit

| # | Issue | Component / Where | Severity | Status | Resolution recommendation |
|---|---|---|---|---|---|
| 1 | Dropdown clear (✕) button also reopens the dropdown | `Dropdown` (`@wix/design-system`) — import config step mapping dropdowns (`ImportStepConfiguration` → `import-mapping-<header>`) | Minor | in progress | Fix in `@wix/design-system` — WDS PR in progress: [wix-design-systems#16421](https://github.com/wix-private/wix-design-systems/pull/16421). Clear handler should `stopPropagation` and not reopen the popover. |
| 2 | "Edit Field" link in the new-field helper is not implemented | Import config step — `NewFieldHelperText` (`ImportStepConfiguration`) | Feature ([CAIRO-4398](https://wix.atlassian.net/browse/CAIRO-4398)) | open | Implement the "Edit Field" entry point: open a field editor from the helper so the user can change the new field's name/type before import. Wire it to the resolved `NewFieldDefinition`. |
| 3 | New field's display name duplicates an existing field name (only the key is deduped) | `ImportState._resolveFieldMapping` / `uniqueFieldNameAndKey` (`packages/core`) | Bug · Minor | **done** | Fixed: `uniqueFieldNameAndKey` now dedupes the **display name** (suffix `-N`) and derives the key from the suffixed name, checking both name and key against existing fields + sibling new fields — mirrors cm-import `generateFieldNameAndKey`. Tests added (duplicate-derived-key + existing-field collision). |
| 4 | Mapping dropdown is missing the "+ Create New Field" footer action | `FieldMappingCell` (`ImportStepConfiguration`) — WDS `Dropdown` `fixedFooter` | Feature ([CAIRO-4399](https://wix.atlassian.net/browse/CAIRO-4399)) | open | Add a sticky "+ Create New Field" footer to the mapping dropdown; clicking opens the field editor (shared with #2) and maps the column to the created field. |
| 5 | New columns don't appear after import — schema isn't reloaded | `ImportState.startImport` (`packages/core`) + consumer schema refresh (auto-patterns) | Bug ([CAIRO-4400](https://wix.atlassian.net/browse/CAIRO-4400)) | open | After a successful import that created new fields, reload the schema so the table columns update. Today only the collection data is refetched (`clearResultAndMoveToStart`); the field/schema definitions aren't refreshed, so new columns stay hidden. |

---

## Details

### 1. Dropdown clear button also opens the dropdown

- **Status:** in progress — fix in `@wix/design-system`, PR
  [wix-design-systems#16421](https://github.com/wix-private/wix-design-systems/pull/16421).
- **Component:** `Dropdown` (`@wix/design-system`) — fix location is WDS, not Cairo.
- **Feature:** Import → "create new field" (CAIRO-4230).

**Symptom:** Clicking a mapping `Dropdown`'s clear (✕) button clears the selected
value but *also* reopens the dropdown popover. Expected: clear should only clear (set
the column to "Don't import"), leaving the dropdown closed.

**Scope:** Specific to the import "create new field" flow — i.e. when `updateSchema`
is provided so columns carry a `(New)` option and default to creating a new field.
Reproduced inside the Import modal; appears tied to the modal context.

**Where observed:** Import modal → "Match & Import" / configuration step, the
per-column mapping dropdowns. Clearing a column mapped to a new field (`(New)`) reopens
the dropdown instead of leaving it on "Don't import".

**Suspected cause (to confirm):** clear → `setMapping(header, null)` re-renders the
cell; combined with the modal focus trap returning focus to the input, the Dropdown's
open-on-focus/click logic re-triggers. The clear handler likely isn't stopping
propagation / preventing the reopen.

**Next steps:**
- [ ] Minimal repro: a `Dropdown` with `clearButton` inside a WDS modal vs. outside,
      and with/without the `(New)` option, to isolate WDS vs. our changes.
- [ ] Confirm whether it's focus-trap-driven (modal) or general.
- [x] File a `@wix/design-system` PR — [#16421](https://github.com/wix-private/wix-design-systems/pull/16421)
      (clear handler should `stopPropagation` and not reopen the popover).
- [ ] Land WDS PR #16421; bump `@wix/design-system` and remove any Cairo-side
      workaround once shipped.

### 2. Implement the "Edit Field" button

- **JIRA:** [CAIRO-4398](https://wix.atlassian.net/browse/CAIRO-4398) (Task, parent CAIRO-3912, Cairo Sprint 101).
- **Type:** Feature.
- **Feature:** Import → "create new field" (CAIRO-4230); design from CAIRO-4131.

**What's missing:** The new-field helper renders `This will be a new text field.`
followed by an **"Edit Field"** link (see design), but the link is not implemented yet
— today the helper text only states the type. The user should be able to click
"Edit Field" to adjust the new field before import.

**Expected behavior:** Clicking "Edit Field" opens a field editor (name + type, and any
other field settings) pre-filled for that column's pending new field. Confirming
updates the column's `NewFieldDefinition` (key/displayName/type) that's later passed to
`updateSchema`. This is also the entry point that, together with CAIRO-4131's type
detection, lets the user override the suggested type.

**Where it goes:** `NewFieldHelperText` in `ImportStepConfiguration` (the helper line
currently shows only the type name). The editor itself likely reuses the existing
field-editing UI (e.g. CustomFieldModal / patterns-fields field editor).

**Next steps:**
- [ ] Open a JIRA ticket for the "Edit Field" flow (link it here).
- [ ] Decide the editor surface (reuse `CustomFieldModal` vs. a lightweight popover).
- [ ] Render the "Edit Field" link in `NewFieldHelperText` and wire it to update the
      column's `NewFieldDefinition` before import.
- [ ] Add the `cairo.import.editField` translation key.

### 3. New field display name can duplicate an existing field name

- **Type:** Bug — in our code (`packages/core` `ImportState`), not external.
- **Feature:** Import → "create new field" (CAIRO-4230).

**Symptom:** The new field's `displayName` is taken straight from the CSV header, so it
can collide with an existing field's display name (or with another new column sharing
the same header). Today only the **key** is deduped (`uniqueFieldKey` — camelCase +
numeric suffix); the display **name** is not, so the UI/schema can end up with two
fields showing the same name.

**Reference:** cm-import `src/field-configuration/generateFieldNameAndKey.js` dedupes
both together — it suffixes the **display name** as `"{name}-{n}"` when the name
collides with an existing field name *or* the derived key collides, then derives the
key from the (suffixed) name. Existing names come from both already-queued new fields
and the current schema fields.

**Fix (done — `ImportState._resolveFieldMapping`):**
- `uniqueFieldNameAndKey(header, usedNames, usedKeys)` replaces `uniqueFieldKey`:
  starts from the header, and when the display name or its derived key collides,
  suffixes the display name as `"<header>-<n>"` and re-derives the key from it.
- `_resolveFieldMapping` seeds `usedNames` (existing `field.header`) alongside
  `usedKeys` (existing `field.id`), and adds each new field's resolved name+key as it
  goes, so both are unique across existing fields and sibling new columns.
- Tests: "dedupes new field name/key when two columns derive the same key" and
  "suffixes a new field when its derived key collides with an existing field"
  (`Table.importButton.spec`, 112 passing).

### 4. Mapping dropdown is missing the "+ Create New Field" footer action

- **JIRA:** [CAIRO-4399](https://wix.atlassian.net/browse/CAIRO-4399) (Task, parent CAIRO-3912, Cairo Sprint 101).
- **Type:** Feature.
- **Feature:** Import → "create new field" (CAIRO-4230); design from CAIRO-4131.

**What's missing:** Per design, the column mapping dropdown should have a sticky
**"+ Create New Field"** footer below the options (suggested `(New)` option + existing
fields). Today the dropdown only offers the auto-suggested `<Column> (New)` option and
the existing fields — no explicit "create a new field" action.

**Expected behavior:** Add a WDS `Dropdown` `fixedFooter` with "+ Create New Field".
Clicking it opens the field editor (the same surface as the "Edit Field" entry point,
#2 / CAIRO-4398) so the user can define a new field (name + type); on confirm the
column maps to that created field, whose `NewFieldDefinition` feeds the single
`updateSchema` call before import.

**Where it goes:** `FieldMappingCell` in `ImportStepConfiguration` — add `fixedFooter`
to the mapping `Dropdown`.

**Next steps:**
- [ ] Add the `fixedFooter` "+ Create New Field" action to the mapping dropdown.
- [ ] Wire it to the field editor (shared with #2 / CAIRO-4398).
- [ ] Map the column to the created field on confirm.
- [ ] Add the `cairo.import.createNewField` translation key.

### 5. New columns don't appear after import (schema not reloaded)

- **JIRA:** [CAIRO-4400](https://wix.atlassian.net/browse/CAIRO-4400) (Task, parent CAIRO-3912, Cairo Sprint 101).
- **Type:** Bug — spans Cairo (`packages/core` `ImportState`) and the consumer
  (auto-patterns schema).
- **Feature:** Import → "create new field" (CAIRO-4230).

**Symptom:** After an import that created new fields completes, the new fields' values
land in the data but the **table doesn't show the new columns** until a manual refresh.
On success `ImportState.startImport` calls `collection.clearResultAndMoveToStart`, which
refetches the collection **data** but not the **schema/field definitions** the table
columns are derived from — so the new columns stay hidden.

**Fix (to decide):** when an import created new fields and completed successfully,
trigger a **schema reload** so the columns update. Options:
- Have `ImportState` invoke an optional completion/`onFieldsCreated` callback the
  consumer wires to `schema.refresh()` (auto-patterns has `schema.refresh`), or
- Refresh the schema in the consumer's import wiring after success.
- Only refresh when new fields were actually created (skip for plain imports), and do
  it post-import (not during) to avoid mid-flight re-render churn.

**Next steps:**
- [ ] Decide the hook: `ImportState` completion callback vs. consumer-side refresh.
- [ ] Trigger `schema.refresh()` (auto-patterns) only when new fields were created.
- [ ] Verify the table renders the new columns after import without a manual reload.