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:
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.
Summary
Add a new repeatable list-style field for patient-style entries such as
Meds,Condition, andAllergy.This should behave like an extension of the existing text/list family rather than a default single-value field:
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:
The desired UX is:
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:
Suggested builder UX:
Preview View
The respondent sees:
Behavior requirements:
Autofill / Suggestions
The field should support contextual suggestions for typing assistance, but it should not behave like a dropdown.
Examples of allowed suggestion behavior:
Examples of behavior to avoid:
Data Shape
Recommended response shape:
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:
Potential configuration options:
maxItemsplaceholdersuggestionContextsuggestionsSourceAcceptance Criteria
Open Questions
string[]or an object with per-item metadata?Notes
The feature name in conversation may be "Meds / Condition / Allergy", but the implementation should probably use a reusable generic label such as:
listrepeatabletextdynamiclistThat keeps the feature reusable across healthcare and non-healthcare forms.