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

Migrate to @react-native-community/react-native-datetimepicker #262

Closed
wants to merge 12 commits into from

Conversation

mmazzarolo
Copy link
Owner

@mmazzarolo mmazzarolo commented Jul 21, 2019

This PR captures the work needed to migrate to the new @react-native-community/react-native-datetimepicker.

Setup:

  • Added @react-native-community/react-native-datetimepicker
  • Updated the dependencies
  • Updated the example

IOS:

  • Implemented @react-native-community/react-native-datetimepicker
  • Simplified the API, removed a few style props (users can still supply their own version of the header/buttons)
  • Find a workaround to this RN issue, easily reproducible by touching the picker without changing the selected value
  • Moved out of react-native-modal

Android:

  • Implemented @react-native-community/react-native-datetimepicker
  • Simplified the API

Docs:

  • Update README.md

Deprecated props:
A few prop names are going to be changed (the old name will still work though).
titleIOS → headerTextIOS
customTitleContainerIOS → customHeaderIOS
onHideAfterConfirm → onHide
customDatePickerIOS → customPickerIOS

Breaking changes:
The following props are not supported anymore:

  • cancelTextStyle → Please use customCancelButtonIOS to override the component instead
  • confirmTextStyle → Please use customConfirmButtonIOS to override the component instead
  • datePickerModeAndroid → Please use the display prop of @react-native-community/react-native-datetimepicker instead
  • dismissOnBackdropPressIOS → This is now the default behaviour on iOS
  • hideTitleContainerIOS → Please set customHeaderIOS to null instead
  • neverDisableConfirmIOS→ This behaviour was causing a few issues with the new picker
  • pickerRefCb→ Not supported by the new picker
  • reactNativeModalPropsIOSreact-native-modal is not being used anymore

@shahzore-qureshi
Copy link
Contributor

Just an FYI - the new repo does not work with Expo. For now, I will continue using this existing repo until the new repo works on Expo.

@mmazzarolo
Copy link
Owner Author

Following #276:
@shahzore-qureshi thanks for reporting! Do you know if the issue is already being tracked in the react-native-datepicker repo?

@mikehardy
Copy link

Hey @mmazzarolo - I'm going to subscribe to this issue, and if you push an rc to npmjs.com with the @next tag I'll pull it down and test if you like, before release. I use this library and doing a quick build+test is simple enough, if that helps. Cheers

@mmazzarolo
Copy link
Owner Author

@mikehardy thank you sir!
I'll release a rc in the next few days.

# Conflicts:
#	README.md
#	src/CustomDatePickerIOS.js
@mmazzarolo
Copy link
Owner Author

@mikehardy since we're using semantic-release it's a bit complex publishing an rc.
I think you can test it with the following command:
npm i mmazzarolo/react-native-modal-datetime-picker#pull/262/head
or
yarn add mmazzarolo/react-native-modal-datetime-picker#262/head

More info here.
Let me know how it goes and thank you!

@mikehardy
Copy link

I am jealous of your semantic-release-ness then ;-), I can use a commit-ish thing like that to pull the code and check it yeah, I'll let you know

"semantic-release": "^15.13.3"
},
"peerDependencies": {
"@react-native-community/datetimepicker": ">=1.0.0"

Choose a reason for hiding this comment

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

this caught me out. I'm usually pretty OCD about this stuff, but I have a stack of 15 peerDependency warnings right now owing to various bits of module non-maintenance, so I did not notice that there was a 16th one, and that I needed to manually add this. It isn't mentioned in the readme diff either, so I'd suggest either moving this to dependencies (like the previous one was) or making sure the readme mentions it and the changelog clearly mentions it as a breaking change / must-do-to-migrate

Copy link
Owner Author

Choose a reason for hiding this comment

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

You're 100% right.
Since this is the most important part of the PR I wanted to add it to both the changelog and the README but I haven't done it yet... should have at least told you before pinging you 🤦‍♂
Thanks for reporting, will add it to the docs soon (when the CHANGELOG is ready).

Copy link
Owner Author

Choose a reason for hiding this comment

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

Please also notice that there are other breaking changes and deprecation (the deprecations are still WIP) in the opening post.

@mikehardy
Copy link

Ok - I made a note on the package.json dependency vs peerDependency and documentation on the actual datetimepicker dependency change - that's easy enough

I had to do a pretty deep-clean (react-native-clean-project's 'wipe iOS build' option) in order for the iOS build to be good but that's a toolchain issue not your module, maybe worth a mention though - I forget the error but it was a redbox in dev about some RNxxx symbol that looked related. I should have taken a screenshot, sorry

Finally, in iOS everything seems fine for my simple use case but Android had an issue where if I cancel the modal goes away but if I hit OK it goes away then pops back, and I have to hit OK a second time before it truly dismisses. Both times my handler is called. I moved the setState for isVisible on the date picker to the first chunk of state I changed in my handler and that seemed to work fine but wasn't important before 🤷‍♂️

All in all, I'd say it looks good but my case is simple. Hopefully my feedback helps

my use case:

  _showDatePicker = () => this.setState({ datePickerVisible: true });
  _hideDatePicker = () => this.setState({ datePickerVisible: false });

  _handleDatePicked = (date: Date) => {
    console.log('a date was picked: ', date);
    console.log('date in milliseconds: ' + date.getTime());
    this._hideDatePicker(); // <--- had to move this here, was above the console.log before
    let updatedUser: User = this.state.user!;
    updatedUser.dateOfBirth = date.getTime();
    this.setState({ user: updatedUser });
    //console.log('user date in millis: ' + this.state.user!.dateOfBirth);
  };
                    <DateTimePicker
                      date={
                        this.state.user && this.state.user.dateOfBirth
                          ? new Date(this.state.user!.dateOfBirth!)
                          : new Date()
                      }
                      isVisible={this.state.datePickerVisible}
                      onConfirm={this._handleDatePicked}
                      onCancel={this._hideDatePicker}
                    />

@mmazzarolo
Copy link
Owner Author

mmazzarolo commented Sep 27, 2019

I had to do a pretty deep-clean (react-native-clean-project's 'wipe iOS build' option) in order for the iOS build to be good but that's a toolchain issue not your module, maybe worth a mention though - I forget the error but it was a redbox in dev about some RNxxx symbol that looked related. I should have taken a screenshot, sorry

Gotcha, thanks for reporting.

Finally, in iOS everything seems fine for my simple use case but Android had an issue where if I cancel the modal goes away but if I hit OK it goes away then pops back, and I have to hit OK a second time before it truly dismisses. Both times my handler is called. I moved the setState for isVisible on the date picker to the first chunk of state I changed in my handler and that seemed to work fine but wasn't important before 🤷‍♂

This sounds like a bug on our side. I wasn't able to reproduce it yet but I'll work on it.

Hopefully my feedback helps

It does, thanks! 🙌

@mmazzarolo
Copy link
Owner Author

I really can't reproduce the issue 🤷‍♀
Anyone willing to test this PR a bit more?

@mikehardy
Copy link

I can't see how that show/hide state thing could be a problem with this library really. I might be having some other thing since my versions are all pretty bleeding - could be tough to reproduce and I don't have the time to try again, sorry - just can say that other than that it worked perfectly?

My tests were on node 12.10.0 with packages at yarn upgrade --latest

@mmazzarolo
Copy link
Owner Author

mmazzarolo commented Oct 17, 2019

Moved to #299
Edit again: moving to an issue so that we can release an rc

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.

3 participants