For me it feels a little more natural to have previous state check on the left hand side - we're used to reading left to right

Why do we early exit here?

Is it a good idea to store a function in navigation?

Why do we need this condition?

This is a potential bug, really hard to debug. Not sure how it works for navigation, but for redux, dispatching an action from a reducer causes some state updates to get lost. In this case it should be probably fine, as we're returning lastState (why?). But we should be really careful about it and verify this thoroughly.

Maybe we should somehow verify that messageListRoute is of correct type and its params are MessageListParams?

Why don't we do anything if the route isn't focused?

I agree

The definition of this function introduces an unnecessary function alias. Can you please remove the unnecessary alias using this patch?

diff --git a/native/utils/edit-messages-utils.js b/native/utils/edit-messages-utils.js
index c85f888bb..dc066b031 100644
--- a/native/utils/edit-messages-utils.js
+++ b/native/utils/edit-messages-utils.js
@@ -14,9 +14,7 @@ function exitEditAlert(onDiscard: () => void): void {
       {
         text: 'Discard edit',
         style: 'destructive',
-        onPress: () => {
-          onDiscard();
-        },
+        onPress: onDiscard,
       },
     ],
   );

1. Are you sure that ChatInputBar will re-render when focus changes? The ReactNav docs don't mention this approach, and instead indicate you should use useIsFocused(). However, the docs warn:

The useIsFocused hook will cause our component to re-render when we focus and unfocus a screen. Using this hook component may introduce unnecessary component re-renders as a screen comes in and out of focus. This could cause issues depending on the type of action we're calling on focusing. Hence we recommend to use this hook only if you need to trigger a re-render.

2. Since you only need "spot checks" and don't need to rerender when things change, it seems like you could pass the isFocused function itself to the component, and call it when necessary to get the current focus state. I'm not sure this will work, but I suspect if the current code has an issue, that this might help.

Can you try to confirm if a change in isFocused triggers a rerender, and if not can you try pass the isFocused function in directly?

Why are we only blocking forward navigation, and not blocking backwards navigation?

My testing seems to confirm that every time focus change a component is rerendered. But The warning won't be there if that was guaranteed, so it's safer to avoid relying on this.

Passing isFocused function is harder, as we're now checking not if a screen is currently focused, but also if it was focused previously.
It seems possible to avoid relying on prev is focused value - we could use something from state instead.

Still, if a rerender isn't guaranteed, passing this function won't change anything, as we need componentDidUpdate to be called.