fix: ensure isReadonly applies to all non-literal date segments

[Persists]

Found During Testing

When isReadonly is set, all segments should be non-editable.

For RAC components, this ensures that when isReadonly is applied to DateField or TimeField, the non-literal DateSegments have isReadonly=true and isEditable=false

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

[snowystinger]

Hey, thanks for the code. Could you provide some tests/add a control to storybook? I'm not able to reproduce the issue.
https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/stories/DateField.stories.tsx#L38
https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/test/DateField.test.js

[nwidynski]

@snowystinger Here is the reproduction: https://codesandbox.io/p/devbox/floral-wind-2fx6pc?workspaceId=ws_nU6d6H4r59ATf4jbZ5rYc

You can see that only the literal elements carry the data-readonly attribute (red background). This is because isEditable in the state does not take isReadOnly into consideration, as we do in the aria layer:

react-spectrum/packages/@react-aria/datepicker/src/useDateSegment.ts

Line 368 in 4b2c6e7

let isEditable = !state.isDisabled && !state.isReadOnly && segment.isEditable;

This causes a mismatch between the data-* props and the aria props, e.g. contenteditable. We can either take isReadOnly into consideration while building the state or possibly just adjust the RAC layer.

To be honest i feel like both isDisabled and isReadOnly should be considered right in the state, but that probably has downstream implications.

[snowystinger]

I'm not sure why the literals have readonly at all, the control is disabled, and the literals aren't interactive to being with. In aria, disabled almost the same as not existing. So it seems to me that readonly is unnecessary and shouldn't even be appearing there unless the control has isReadOnly
Also, those are literals, they are readonly to start with and the data-attribute won't be read.

Maybe we should back up, what is the use case you're trying to build?

[nwidynski]

@snowystinger No use case besides styling being difficult right now for isReadOnly, as its neither applied to all segments nor on the parent field. Our component test suite prompted us with this issue.

[LFDanLu]

@nwidynski Just to clarify, the expectation here would be that data-readonly would only appear on the segments when isReadOnly is set on the DateField but NOT when isDisabled is applied correct?

[nwidynski]

@LFDanLu Yep. We had expected data-readonly to appear on ALL segments when isReadOnly is set on the field.