Fix mobile crash on drawer dismiss

[dharit-tan]

Description

EDIT: found the real bug - we had ordered events incorrectly in the callback hooked into the drawer slideOut animation. We were actually setting visibility to false first, and then 'closing', this entire time!

Bug on mobile prod - if you swipe down to dismiss a drawer that reads drawer data like this: const { data } = useDrawer(drawerName), app crashes. For some reason even after dismissing, the app tries to render the drawer, but now the data field in drawer slice is null. Easy fix is to just add const { collectionId } = data ?? {} to avoid destructuring null, but i feel like there should be a better pattern here. /should maybe figure out why the dismissed drawer is still being rendered. Any ideas?
Can't add ?? {} in the selector or hook bc that gives type errors when we try to destructure in a component.
Example drawer is BlockMessagesDrawer (from profile screen top right)

Can bikeshed this later but probably good to get a fix out to prod asap.

Dragons

Is there anything the reviewer should be on the lookout for? Are there any dangerous changes?

How Has This Been Tested?

Local ios stage

How will this change be monitored?

For features that are critical or could fail silently please describe the monitoring/alerting being added.

Feature Flags

Are all new features properly feature flagged? Describe added feature flags.

[dylanjeffers]

great job, can also do const collectionId = data?.collectionId for these, but all good either way :)

[rickyrombo]

What a find!

IIUC: onFinished calls onClose, which would set the state back to closing but without any data?

[dharit-tan]

I think onFinished calls onClose which sets to closing, and then onClosed (note closed instead of close) sets to false.
Monitoring the actions in redux, the ordering of events looks correct.

[rickyrombo]

yeah makes sense, saying the same thing, I was describing the error case 👍