feat(form-builder): toggle multi select visibity based on prop - #1007
feat(form-builder): toggle multi select visibity based on prop#1007sampath-E1005112 wants to merge 3 commits into
Conversation
| return null; | ||
| } | ||
| const strFieldType = dataItem.type; | ||
| if (strFieldType === 'MULTI_SELECT' && !this.showMultiSelectField) { |
There was a problem hiding this comment.
P0-1 — Possible reorder index mismatch when hidden MULTI_SELECT fields exist in loaded schemas
Context (from this PR): This guard removes existing MULTI_SELECT fields from the DOM (return null) while they remain in localFormValues.fields.
Concern: Visible fb-field-drag-drop-item elements keep original array index props, but droppedIndex in fieldTypeDropHandler / fwRepositionField.emit (~line 695) is computed from visible DOM children only (draggable.ts). If a hidden MULTI_SELECT sits mid-list, reorder may emit a targetIndex that maps to the hidden slot.
Goal-dependent — please confirm intent:
- Greenfield only (no existing multi-select in schema) → likely fine.
- Legacy schemas with existing
MULTI_SELECT+ drag-and-drop reorder → likely needs a fix or documented limitation.
| return null; | ||
| } | ||
| const strFieldType = dataItem.type; | ||
| if (strFieldType === 'MULTI_SELECT' && !this.showMultiSelectField) { |
There was a problem hiding this comment.
P1-1 — Existing MULTI_SELECT fields become invisible but stay in formValues
Context (from this PR): Same guard — hides the editor for existing MULTI_SELECT when the flag is false.
Concern: Field data remains in localFormValues.fields and will still be included on save, but users cannot edit, delete, or reorder via the UI. Note: showLookupField=false still renders existing relationship editors — this prop is more aggressive.
Goal-dependent — please confirm intent:
- Hide new creation only → may be acceptable.
- Fully unsupported product with legacy schemas → consider read-only/disabled UI (with delete?) or document that hosts must filter on save.
| arrFieldOrder.splice(dependentIndex, 1); | ||
| } | ||
| } | ||
| if (!this.showMultiSelectField) { |
There was a problem hiding this comment.
P1-2 — Widget customize modal may still expose MULTI_SELECT (unchanged path, triggered by partial hide in this PR)
Context (from this PR): Multi-select is hidden in left nav + field editor, but renderWidgetElement (~line 1504) and openCustomizeWidgetModalHandler (~line 830) were not updated. CUSTOM_OBJECTS has "customizeWidget": true.
Concern: Users may still see/select MULTI_SELECT in the customize-widget modal, and fwSaveWidgetFields may include those IDs — inconsistent with the hide goal elsewhere.
Goal-dependent — please confirm intent:
- Hide from field builder only → may be OK to leave.
- Fully invisible when flag is false → guard
renderWidgetElement+ filter inopenCustomizeWidgetModalHandler.
Your call: In scope for this PR, or follow-up?
| arrFieldOrder.splice(dependentIndex, 1); | ||
| } | ||
| } | ||
| if (!this.showMultiSelectField) { |
There was a problem hiding this comment.
P1-3 — Search empty-state may break for hidden MULTI_SELECT matches (downstream of render guard in this PR)
Context (from this PR): searchChangeHandler (~738) is unchanged and can still match MULTI_SELECT fields (e.g. label "People"). But renderFieldEditorElement now returns null for them, so fieldElements can be [null]. boolShowEmptySearchResults (~line 1610) checks array length, not rendered count → blank panel instead of "no results".
Goal-dependent — please confirm intent:
- Schemas without multi-select → low priority.
- Legacy schemas + search enabled → fix empty-state (
fieldElements.filter(Boolean).length) and/or exclude hidden types in search.
Your call: Known limitation, fix in this PR, or follow-up?
2 participants
Checklist:
How Has This Been Tested?