Skip to content

DRYD-1294: Use Native Date Input - #29

Open
mikejritter wants to merge 8 commits into
collectionspace:mainfrom
mikejritter:bug/dryd-1294-date-input
Open

mikejritter wants to merge 8 commits into
collectionspace:mainfrom
mikejritter:bug/dryd-1294-date-input

Conversation

@mikejritter

Copy link
Copy Markdown
Contributor

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

@mikejritter
mikejritter requested a review from spirosdi October 13, 2026 21:25
@mikejritter
mikejritter force-pushed the bug/dryd-1294-date-input branch from 8425c46 to 448a24c Compare October 13, 2026 22:59
@spirosdi

Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants