Delayed onChange

[zlanich]

The onChange event currently doesn't fire until the closing animation is 100%, done if not later. This causes the UI to not be updated to the new value (at least when using a custom selector component), until about a full second later.

Would it be possible to fire the onChange event right away instead of after the animation?

I don't see a reason that would be problematic. Thoughts?

[peacechen]

That should be ok. Please submit a PR and we'll merge right away.

[mikaello]

I agree that conceptual this should be just fine. Just be aware of an issue regarding iOS and onChange while closing a modal. The way it is done today is to prevent this issue. I guess it is possible to do this in other ways, just remember to test on iOS with alert (e.g. the SampleApp). Related issues:

• RN-repo: iOS: UI will be blocked when show Alert while closing Modal
• RN-repo: Controlled Modal UI Freezes
• This repo: Alert does not work in SampleApp for iOS

[zlanich]

@mikaello All good points. My one thought is this: Isn't the issue of an Alert interrupting the JS thread an issue in a million different ways? I feel like this issue would pop up in every project if you're firing off an Alert when an animation or other process may be running.

Is that even something worth sacrificing UI feedback/response to fix, something where the likely better solution would be to use a non-blocking Alert alternative? I feel like it's similar to alerts in a web browser. They're kind of lame to begin with, and most mature web apps don't use them anyway.

[manhthepixta]

I noticed the delay too. Could it be merged anyway?

[peacechen]

Hopefully this doesn't cause unintended side effects. If it does, we could add a prop to control the onChange behavior -- previous work-around or none.