keystone

keystone copied to clipboard

Closes https://github.com/keystonejs/keystone/issues/7638

In integer and bigInt fields I have changed the TextInput type to text (instead of number), this allows to enter commas, the filtering of the value (only digits, commas and minus sign) is already performed by a regex on the onChange handler. With this change the filtering works as expected.

There is a comment above the TextInput regarding the type change but I'm not sure this is an old comment (prior to the onChange regex) or if we want to have a more advanced input.

https://github.com/keystonejs/keystone/blob/df88fe6c49c6e15acea45e00192a3c8d16a3d461/packages/core/src/fields/types/integer/views/index.tsx#L213-L216

🦋 Changeset detected

Latest commit: 8541b89024079b787a545c3d49fabb7da176f715

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@keystone-6/core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
keystone-next-docs	✅ Ready (Inspect)	Visit Preview	Oct 26, 2022 at 6:24AM (UTC)

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 8541b89024079b787a545c3d49fabb7da176f715:

Sandbox	Source
@keystone-6/sandbox	Configuration

Thanks @nya1 and @gautamsi - it is unfortunate that these fields are not locale friendly. I have updated the pull request to try and increase the consistency of the filters across each of the numeric fields, but honestly these need work and attention. :yellow_heart:

We're currently experimenting with Adobe Spectrum in Keystone's updated design system, and that, or something like it, should help us unify and smooth the user experience across many of these field views.

We're currently experimenting with Adobe Spectrum in Keystone's updated design system, and that, or something like it, should help us unify and smooth the user experience across many of these field views.

does this mean end of @keystone-ui or just use their design system with @keystone-ui for implementing the design? you mentioned locale, is this going to help improve locale in admin-ui and content? Also new design system should make it possible to use new Admin-ui over the headless api instead of tightly coupled in terms of generation and consumption of admin meta.

@gautamsi We're interested in react-aria specifically for accessibility. Since they also provide I18N solutions we'll be considering that too.

The intention is to build a component library that's informed by and in service of, but decoupled from, the admin UI. Ideally consumers will be able to pick up the same pieces to build custom interfaces that fit seamlessly within Keystone's overall aesthetic and behaviour.