@tomek more context about this diff:

The order of modifications in this actions is:

1. Create an operation to replace the message with id localID
2. Processing this operation
3. Checking if the message with localID exists in the old state, and if yes:
   • update threads and local
   • return the modified store with messages processed by ops previously
4. Iterate over messageIDs in this thread and if a message exists and has the same localID return the old store with empty ops (which means 1 and 2 were useless)
5. Update threads
6. Return updated threads and messages processed by ops from step 2.

Which I believe is complicated and adding ops for threads will complicate code even more, we can change the order (the only downgrade will be that indentation will increase a bit), I would suggest something like this (new order):

1. Make sure that is no message with id === localID in the store, and iterate over all messageIDs, and if a message with the same localID exists return old state. (current step 4).
2. Create an operation to replace the message with id localID (current step 2)
3. Checking if the message with localID exists, and:
   • a. if yes - update local and threads (generate ops for threads) (current step 3)
   • b. if no - update threads (generate ops for threads) (current step 5)
4. Process operations
5. Return state with modified threads and messages processed by ops

Otherwise, we will have to process ops multiple times and compare results multiple times which I think is bad.

@tomek let me know if this helped you, otherwise, I will try to split this or change the approach

extract shared code and rebase