DRYD-1294: Use Native Date Input by mikejritter · Pull Request #29 · collectionspace/cspace-input.js

mikejritter · 2026-10-13T21:24:56Z

What does this do?

Migrates DateInput to a functional component
Removes react-calendar from DateInput in favor of the browser's native date input handling
Update DateInput tests

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-1294

The current implementation of the DateInput uses a Dropdown which opens the react-calendar widget, and was flagged in the accessibility audit. This switches to using the browser's native date input as it is generally made to be accessible.

A few notes on some of the changes:

In DateInput
- the BaseDropdownInput propTypes were removed in favor of directly managing the necessary input propTypes (name, parentPath, subpath, etc).
- I opted for normalizeDateString as it calls both normalizeISO8601DateString and normalizeNaturalLanguageDateString. I don't expect we'll have anything with natural language, but it seemed harmless.
- Styling now uses the LineInput css directly to keep it similar to other input in forms
In DateInput.spec
- Many tests were removed which were related to the old implementation, e.g. locale (handled by the browser), partial dates (not supported via the new form afaik), some onChange behavior (we only receive input when the native widget passes it).

How should this be tested? Do these changes have associated tests?

In cspace-ui.js, update your package.json to use this version of cspace-input, e.g.
"cspace-input": "file:../cspace-input.js",
run the devserver
In the advanced search form
- Search for a field which uses DATA_TYPE_DATE, e.g. annotationDate for CollectionObjects
- Use the updated input and verify the data displays correctly and is used correctly in the search API
In the record editor form
- Create a record with a field which uses the DATA_TYPE_DATE and ensure the record data persists
- Load a record and see the DateInputs filled out with existing data

Dependencies for merging? Releasing to production?
The CHANGELOG still needs to be updated. 2.4.0? 2.3.1? I can do it here once we decide.

The tooltip was removed so there's likely some dead code paths from cspace-ui.js now. I don't believe any of the other input components use a tooltip, probably worth checking.

Has the application documentation been updated for these changes?
If there's documentation about the date input it will need to be. I'll search.

Did someone actually run this code to verify it works?
@mikejritter tested locally

spirosdi · 2026-10-16T07:53:14Z

Regarding which version to use in the CHANGELOG, I set it to 2.3.1 in another PR. Let's for the moment do a patch bump and use dev releases. When done with the Sprint, we can decide if it is a patch or a minor one.

spirosdi · 2026-10-19T07:48:24Z

+      data-name={name}
+      className={className}
+      value={normalizedValue}
+      onChange={handleChange}


The native date input (at least in Chrome) fires a change event per keystroke inside a segment. Typing the year 2025 over an existing 2025-12-01 produces "0002-12-01", "0020-12-01", "0202-12-01" and then "2025-12-01". Each one is committed. Clearing a segment commits "" as well. (As a side effect, the round trip through normalizeDateString shifts those (before 1000 year) years back a day, so the field visibly jumps around while typing.)

Could we use the changeable and committable enhancers instead, as the other text inputs do, so the value being edited is held locally and only committed on blur or enter? A BaseDateInput here can hold the native <input type="date">. This component can render committable(changeable(BaseDateInput)). handleChange and the getPath import can then go away.

spirosdi · 2026-10-29T08:48:17Z

+  parentPath: pathPropType,
+  subpath: pathPropType,
+  value: PropTypes.string,
  locale: PropTypes.string,


Suggested change

locale: PropTypes.string,

spirosdi · 2026-10-29T08:48:17Z

+  parentPath: undefined,
+  subpath: undefined,
+  value: undefined,
  locale: 'en-US',


Suggested change

locale: 'en-US',

spirosdi · 2026-10-29T08:48:17Z

+    onCommit,
+    asText,
+    embedded,
+    locale,


Suggested change

locale,

spirosdi · 2026-10-29T08:48:17Z

+  } = props;
+
+  const className = embedded ? styles.embedded : styles.normal;
+  const normalizedValue = normalizeDateString(value, locale) || '';


Suggested change

const normalizedValue = normalizeDateString(value, locale) || '';

spirosdi · 2026-10-29T08:48:17Z

+      <LineInput
+        id={id}
+        asText={asText}
+        value={normalizedValue}


Suggested change

value={normalizedValue}

value={value}

spirosdi · 2026-10-29T08:48:17Z

+      type="date"
+      data-name={name}
+      className={className}
+      value={normalizedValue}


Suggested change

value={normalizedValue}

value={value}

spirosdi · 2026-10-29T08:51:13Z

+  } = props;
+
+  const className = embedded ? styles.embedded : styles.normal;
+  const normalizedValue = normalizeDateString(value, locale) || '';


I still can see the jump around while typing. The root cause is calling the normalizer here. This results to normalizing values typed on every keystroke. Let's follow the pattern used before switching to native. Having a wrapper that calls the normalizer once. I had to apply the fix locally to test it, so I also add the relevant suggested changes.

I wonder if I need to change my locale to see the jumping behavior (which makes sense with normalize being called so often). Let me see if I can do that then I'll pull in your changes.

Oh nevermind, I see it in chrome as well. I must have only tested onCommit being called from the calendar input the other day.

This wraps the BaseDateInput to allow normalization to happen only when a date is committed and not while being edited. Co-authored-by: Spiros Dimopulos <spiros@wantedpixel.com>

mikejritter added 4 commits October 13, 2026 15:22

Switch to functional component and use native date input

fac6134

Remove tests which no longer apply

a653bb3

Update tests

7aea7c8

Remove unused styles

e6a3373

mikejritter requested a review from spirosdi October 13, 2026 21:25

mikejritter added 2 commits October 13, 2026 15:32

Remove react-calendar from dependencies

277cb3c

Fix typo in test

448a24c

mikejritter force-pushed the bug/dryd-1294-date-input branch from 8425c46 to 448a24c Compare October 13, 2026 22:59

mikejritter added 2 commits October 16, 2026 14:25

Merge branch 'main' into bug/dryd-1294-date-input

ef12dc8

Update CHANGELOG

c984509

spirosdi requested changes Oct 19, 2026

View reviewed changes

Use changeable and committable enhancers for DateInput

b460709

mikejritter changed the base branch from main to develop October 28, 2026 19:09

Merge branch 'develop' into bug/dryd-1294-date-input

e64e553

mikejritter requested a review from spirosdi October 28, 2026 19:12

spirosdi requested changes Oct 29, 2026

View reviewed changes

mikejritter and others added 2 commits October 29, 2026 11:36

Add EnchancedDateInput

150f70b

This wraps the BaseDateInput to allow normalization to happen only when a date is committed and not while being edited. Co-authored-by: Spiros Dimopulos <spiros@wantedpixel.com>

Apply the rest of the suggestions

09c6770

spirosdi approved these changes Oct 30, 2026

View reviewed changes

Merge branch 'develop' into bug/dryd-1294-date-input

4ee1aeb

mikejritter merged commit b69f3e4 into collectionspace:develop Oct 30, 2026

mikejritter deleted the bug/dryd-1294-date-input branch October 30, 2026 22:10

Navigation Menu

Repository navigation

DRYD-1294: Use Native Date Input - #29

DRYD-1294: Use Native Date Input#29
mikejritter merged 13 commits into
collectionspace:developfrom
mikejritter:bug/dryd-1294-date-input

mikejritter commented Oct 13, 2026

Uh oh!

spirosdi commented Oct 16, 2026

Uh oh!

spirosdi Oct 19, 2026 •

edited

Loading

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

Uh oh!

spirosdi Oct 29, 2026

Uh oh!

mikejritter Oct 29, 2026

Uh oh!

mikejritter Oct 29, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mikejritter commented Oct 13, 2026

Uh oh!

spirosdi commented Oct 16, 2026

Uh oh!

spirosdi Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

spirosdi Oct 19, 2026 •

edited

Loading