Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(Field.Date): add DatePickerProps #4160

Merged
merged 43 commits into from
Nov 18, 2024
Merged

Conversation

joakbjerk
Copy link
Contributor

@joakbjerk joakbjerk commented Oct 21, 2024

  • Add documentation
  • Add some tests
  • Double check if any of the props needs accommodate for field props
  • Fix startMonth and endMonth bugs
  • Fix date correction test
  • Merge DatePicker camelCase changes

Copy link

vercel bot commented Oct 21, 2024

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

Name Status Preview Comments Updated (UTC)
eufemia ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 6:49am

Copy link

codesandbox-ci bot commented Oct 21, 2024

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.

@langz langz force-pushed the feat/field-date-datepicker-props branch from e11a274 to 3aa1f89 Compare November 8, 2024 14:40
@joakbjerk joakbjerk requested a review from langz November 15, 2024 12:57
Copy link
Contributor

@langz langz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice nice 👏

I'm not 100% sure why we've needed to make changes in DatePicker though 🤔

@joakbjerk
Copy link
Contributor Author

Nice nice 👏

I'm not 100% sure why we've needed to make changes in DatePicker though 🤔

Just to make it easier to filter out props that we don't want to be used as html attributes for the span element that wraps all the DatePicker related components. I got a couple of "X is not a valid html attributes, write it in lower case if you want to use it as such"-error messages.

And it also removes the weird bracket encapsulation around the block of code where the attributes gets re-assigned to the restProps. Also removes the need for the attributes to be a let, just so we could re-assign the attributes variable inside the bracket encapsulation.


export type TranslationsNbNO = (typeof locales)['nb-NO']
export type TranslationsEnGB = (typeof locales)['en-GB']
export type TranslationsEnUS = (typeof locales)['en-US']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these changes intentional and needed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume not, and will revert this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But when I did so, multiple tests fail 😢

@langz
Copy link
Contributor

langz commented Nov 17, 2024

I've:

After reverting the removal of en-us locale, tests starts failing 😢

@joakbjerk
Copy link
Contributor Author

I've:

After reverting the removal of en-us locale, tests starts failing 😢

The en-us was added in the camelCase pr, but then i noticed that we dont document it as being exported by default in the translation object, so I removed it in this pr since it fucks up all the tests involving the datepicker input, that runs after the us locale test for Field.Date. so by removing it, the translation object reverts to how it was before the camelCase pr

@langz
Copy link
Contributor

langz commented Nov 18, 2024

I've:

After reverting the removal of en-us locale, tests starts failing 😢

The en-us was added in the camelCase pr, but then i noticed that we dont document it as being exported by default in the translation object, so I removed it in this pr since it fucks up all the tests involving the datepicker input, that runs after the us locale test for Field.Date. so by removing it, the translation object reverts to how it was before the camelCase pr

Ok ok, thanks :)
A bit difficult for me to understand that that change could be related to this feature.
I've once again removed en-us locale d188d66

is this something we should follow-up @joakbjerk? Or is it fine as it is now?

@langz langz merged commit 6a3765b into main Nov 18, 2024
8 of 10 checks passed
@langz langz deleted the feat/field-date-datepicker-props branch November 18, 2024 06:44
tujoworker pushed a commit that referenced this pull request Nov 18, 2024
## [10.56.0](v10.55.1...v10.56.0) (2024-11-18)

### 🐛 Bug Fixes

* **DatePicker:** ensure that `endMonth` does not fallback to `startMonth` when `endMonth` prop is defined ([#4254](#4254)) ([5281257](5281257))
* **Forms:** render given elements to `warning` and `info` properties ([#4261](#4261)) ([d60de25](d60de25))

### ⚡ Refactoring

* **DatePicker:** convert properties to camel case and deprecate those with snake case ([#4273](#4273)) ([a69a8aa](a69a8aa))

### ✨ Features

* **Field.Date:** add DatePickerProps ([#4160](#4160)) ([6a3765b](6a3765b))
* **Forms:** add `asyncFileHandler` to Field.Upload to support async file handling during upload ([#4281](#4281)) ([030a09c](030a09c))
* **Forms:** add inline HelpButton to all Field.* components as default (with option to open in Dialog) ([#4282](#4282)) ([e869a60](e869a60))
* **Forms:** add support for multiple info, warning and error messages given by an array ([#4284](#4284)) ([78f2fe8](78f2fe8))
* **ListFormat:** adds spacing properties ([#4255](#4255)) ([c72d999](c72d999))
* **Paragraph:** handle nested paragraphs (to be `span`'s) ([#4251](#4251)) ([ca3bbde](ca3bbde))
@tujoworker
Copy link
Member

🎉 This PR is included in version 10.56.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@joakbjerk
Copy link
Contributor Author

I've:

After reverting the removal of en-us locale, tests starts failing 😢

The en-us was added in the camelCase pr, but then i noticed that we dont document it as being exported by default in the translation object, so I removed it in this pr since it fucks up all the tests involving the datepicker input, that runs after the us locale test for Field.Date. so by removing it, the translation object reverts to how it was before the camelCase pr

Ok ok, thanks :) A bit difficult for me to understand that that change could be related to this feature. I've once again removed en-us locale d188d66

is this something we should follow-up @joakbjerk? Or is it fine as it is now?

I think it's fine as it is now @langz 🤔

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

Successfully merging this pull request may close these issues.

3 participants