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

[mmazzarolo]

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
• reactNativeModalPropsIOS → react-native-modal is not being used anymore

[shahzore-qureshi]

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]

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

[mikehardy]

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]

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

[mmazzarolo]

@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]

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

[mikehardy]

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

[mmazzarolo]

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).

[mmazzarolo]

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

[mikehardy]

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]

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]

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

[mikehardy]

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]

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