Adding keyboardHiding and keyboardShowing state flags to useKeyboard

[rhdeck]

Summary

This feature exposes transitional flags, keyboardHiding and keyboardShowing for when the keyboard is in the process of animating in and out.

This is handy for preparing changes in layout that we wish to be true at the end without observing the late jank when the keyboard "lands" (e.g. by waiting for keyboardShown to be true.

Use Case: In iPhone X/11/S configurations, it can be handy to have a different treatment of SafeAreaContext insets when keyboard is up vs down. e.g. the sample/test below

Test Plan

This is a really simple change. It allows the following style configuration to work nicely:

const { keyboardHiding, keyboardShowing, keyboardShown} = useKeyboard()
{
marginBottom:
      keyboardHiding || (!keyboardShown && !keyboardShowing)
        ? insets.bottom
        : 0,
}

What's required for testing (prerequisites)?

Nothing, this is a really simple change. Results are clearest on an iPhone X-like.

Compatibility

OS	Implemented
iOS	✅
Android	✅
Web	❌

Checklist

• [X] I have tested this on a device and a simulator
• [X] I added the documentation in README.md
• [X] I updated the typed files (TS )

[LinusU]

Hey 👋

Thanks for the PR! Did you see #140, do you think that maybe that is a better approach? or do you think that we need both?

[rhdeck]

It's a simplicity vs precision tradeoff.

The benefit of this approach is being able to very easily and simply trigger a style (or any other behavior) during the fast transition without worrying about matching every frame. It's an immediate improvement over using keyboardShown for the X-class insets problem and requires very little advanced knowledge to exploit.

#140 seems very cool. In order to work, it needs a level of frame-by-frame precision matching the curve of each device's keyboard animation that is important to get right for its implementation that means more dev and probably more testing. I'll be interested in checking it out when it merges!

I'd have this repo support both in the longer run to give both power and ease-of-use. But probably this PR can be merged first for its simplicity, and #140 when it is ready and tested.