-
Notifications
You must be signed in to change notification settings - Fork 1
feat(Form): Add <PhoneInput /> and <DateInput />; Clean up <Select /> #34
Conversation
Codecov Report
@@ Coverage Diff @@
## master #34 +/- ##
==========================================
- Coverage 88.88% 67.69% -21.2%
==========================================
Files 13 21 +8
Lines 198 421 +223
Branches 31 88 +57
==========================================
+ Hits 176 285 +109
- Misses 15 106 +91
- Partials 7 30 +23
Continue to review full report at Codecov.
|
@heydoctor/engineering |
EDIT: removing
|
@kylealwyn Played around with the inputs to try and break them. Let me know if these are valid bugs: Trying to delete a backslash makes the cursor jump to the end: Trying to delete a parenthesis makes the cursor jump to the end: |
src/Form/PhoneInput.js
Outdated
} | ||
}; | ||
|
||
return <Input forwardedRef={ref} value={currentValue} onChange={handleChange} {...inputProps} />; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should we set a
maxLength
of 10 numbers (or 11 with country code)? - Can we make this input
type="tel"
by default so we can have a numpad on mobile devices?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we specify the expected format as a parenthetical aspect in the label (e.g. (123) 123-1234). Should we also allow the character required for the format? For example, if a user types in "(" they are currently blocked from doing so, which might be unintuitive if the format is specified in the label. Or maybe not. Perhaps we could consider masking (https://www.uxbooth.com/articles/the-new-rules-of-form-design/, https://uxplanet.org/designing-perfect-text-field-clarity-accessibility-and-user-effort-d03c1e26004b).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That behavior is dictated by Google's libphonenumber
to disallow the leading paren so I'd rather not get in the way. It's also more difficult to type a paren on mobile when the numpad is presented.
@erikshestopal Country code support is in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are really slick. I agree with Erik's comments.
<option value="">{placeholder || 'Select an option...'}</option> | ||
<SelectContainer value={value} size={size}> | ||
<SelectInput name={name} value={value} onChange={this.handleChange} onBlur={this.handleBlur}> | ||
<SelectOption value="">{placeholder || 'Select an option...'}</SelectOption> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These guidelines advise against using an option to replace a label (which is not exactly what is happening here): https://designsystem.digital.gov/components/form-controls/
Instead, we could add any additional guidance as a parenthetical portion of the label: States (please select a state), as it seems like the label is typically used to convey instructions to users.
Additional examples:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html
https://webaim.org/techniques/forms/controls
http://www.webaxe.org/accessible-custom-select-dropdowns/
src/Form/PhoneInput.js
Outdated
} | ||
}; | ||
|
||
return <Input forwardedRef={ref} value={currentValue} onChange={handleChange} {...inputProps} />; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we specify the expected format as a parenthetical aspect in the label (e.g. (123) 123-1234). Should we also allow the character required for the format? For example, if a user types in "(" they are currently blocked from doing so, which might be unintuitive if the format is specified in the label. Or maybe not. Perhaps we could consider masking (https://www.uxbooth.com/articles/the-new-rules-of-form-design/, https://uxplanet.org/designing-perfect-text-field-clarity-accessibility-and-user-effort-d03c1e26004b).
5d1636f
to
c794767
Compare
…p to DateInput (#36) ## Fix I forgot to include theses exports in #34 😞Seems like something a robot should disallow ## Add Also adds support to DateInput for an `initialValue` prop. This solves an issue where the database stores ISO dates (YYYY-MM-DD) but we want to display MM/DD/YYYY on the client. We can't format the `value` prop, otherwise we'll incorrectly format incomplete dates on every render.
<PhoneInput />
and<DateInput />
components for easy input masking<Select />