Ideally, we could use loadingStatus here. The problem with this is that we're updating the button using setOptions from navigation, which is slow and still allows multiple interactions before the correct state is rendered.

Either way you're updating the button via setOptions, right? And either way you'll need a check in updateRelationshipsOnServer to deal with that.

I imagine it might be slower to check loadingStatus inside updateRelationshipsOnServer instead of this ref because loadingStatus only updates later, after the first action is reduced. I'm guessing you could get multiple clicks in before this gets processed.

Either way you're updating the button via setOptions, right?

Yes

And either way you'll need a check in updateRelationshipsOnServer to deal with that.

Not necessarily, because updateRelationshipsOnServer callback would depend on the loadingStatus so if the update to the button was immediate (in the next render) then it would be relatively safe.

I imagine it might be slower to check loadingStatus inside updateRelationshipsOnServer instead of this ref because loadingStatus only updates later, after the first action is reduced. I'm guessing you could get multiple clicks in before this gets processed.

My use of the word slow was unfortunate. What happens here is that updateRelationshipsOnServer is a callback that would depend on the loadingStatus. After loadingStatus changes, an effect would be run and call setOptions with a new onPressAdd that depends on updateRelationshipsOnServer. It takes some time for the setOptions call to take effect, which means that for a couple of renders the button would still have a callback with an outdated loadingStatus bound. So overall, checking the loadingStatus isn't slow, but reflecting its change in the UI is.