Skip to content

New Field: Dynamic List Field (Allergy, Conditions, Meds #84

Description

@lattln

Summary

Add a new repeatable list-style field for patient-style entries such as Meds, Condition, and Allergy.

This should behave like an extension of the existing text/list family rather than a default single-value field:

  • Builder view: the field appears as a configurable list field
  • Preview view: the user sees a question plus a text input with the ability to keep adding more items
  • Output: the response is a dynamic list of entered values

Problem Statement

The current field set covers single text inputs and fixed multi-input patterns, but it does not provide a clean way to capture an open-ended list of text entries.

Examples that need this behavior:

  • Medication lists
  • Conditions
  • Allergies
  • Other repeating free-text entries

The desired UX is:

  • the author enters a question like "List your current medications"
  • the respondent enters one item at a time
  • the respondent can add more rows as needed
  • the builder can cap the maximum number of items
  • the builder can provide contextual autofill suggestions without turning the field into a dropdown

Proposed Field Behavior

Builder View

The builder should present this as a list field with editable settings, similar to other answer-bearing fields.

Required builder controls:

  • Question text
  • Placeholder text for each row
  • Maximum item count
  • Optional suggestion/autofill context

Suggested builder UX:

  • "Add item" button for adding more rows in the preview
  • Per-item remove control
  • Drag/reorder support only if it fits the existing builder patterns

Preview View

The respondent sees:

  • the question label
  • a text input for the first item
  • an "Add another" control
  • repeated text inputs for each added item

Behavior requirements:

  • users can add multiple entries
  • each entry is free text, not a select menu
  • the field should stop adding rows at the configured max count
  • empty rows should not be included in the final response

Autofill / Suggestions

The field should support contextual suggestions for typing assistance, but it should not behave like a dropdown.

Examples of allowed suggestion behavior:

  • autocomplete hints from form variables
  • typeahead suggestions from a configured list
  • contextual chips or inline hints

Examples of behavior to avoid:

  • hard select-only choices
  • a forced dropdown experience
  • locking the user into predefined values

Data Shape

Recommended response shape:

  • ordered array of strings

Example:

{
  "meds": ["Metformin", "Aspirin 81 mg"],
  "conditions": ["Diabetes", "Hypertension"],
  "allergies": ["Penicillin"]
}

If the implementation needs item metadata later, the schema can be expanded, but the first version should stay simple and easy to render.

Builder Notes

The field should likely be added as a new custom field type or a dedicated extension of the existing text-list pattern.

It should inherit the usual field capabilities:

  • question text
  • required handling
  • validation hooks
  • builder preview/edit split

Potential configuration options:

  • maxItems
  • placeholder
  • suggestionContext
  • suggestionsSource

Acceptance Criteria

  • A form author can add the new list field from the builder
  • The builder lets the author edit the question and configure the list behavior
  • The preview renders a question plus a repeatable text input list
  • Users can add more items until the max count is reached
  • The response is stored as a list of entered text values
  • Autofill support helps typing without converting the field into a dropdown

Open Questions

  • Should this be a brand-new field type or a specialized variant of an existing text field?
  • Should the stored value be string[] or an object with per-item metadata?
  • Should suggestions be based on form variables, static presets, or both?
  • Should the field support reorderable rows on the respondent side?

Notes

The feature name in conversation may be "Meds / Condition / Allergy", but the implementation should probably use a reusable generic label such as:

  • list
  • repeatabletext
  • dynamiclist

That keeps the feature reusable across healthcare and non-healthcare forms.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions