We should not add the same string twice, you can reuse it.

Hi @HaonRekcef,

Thanks for the link. I changed it. Deleted the translations and made use of hardcoded text. Re-used the code mobileAreYouSure .

Can you tell me why you invalidate here?

And why after pushing the screen? Usually what we do is invalidate, then push.

We invalidate the provider after returning from the profile screen because the user may have blocked the contact while viewing their profile. The server's /inbox endpoint does not return blocking status, so the controller calls getUser() to fetch it separately. By invalidating after the push returns, we force the controller to rebuild and call getUser() again picking up any blocking change that happened while on the profile screen.

Invalidating before the push would not help here, since the block action hasn't occurred yet at that point and the controller would just reload with the same unblocked state.

I see. I actually got confused because this is the first time I see an async onTap handler doing it.

In other parts of the code we're doing:

onTap: () {
   Navigator.push(context, UserOrProfileScreen.buildRoute(context, widget.user))
     // invalidate to refresh potential blocking status change
     .then((_) => ref.invalidate(conversationControllerProvider(widget.user.id)))
}

I know async/await is most of the time preferred to .then but in that case I find it more intuitive (and let's be consistent with the rest).

Also here I think we miss a if (context.mounted) after the async gap.

Will make it consist with the rest of the code and also add the if (context.mounted) and push later today.

You removed that logic. I am not sure why?

We could use tests here. At least to check which convo is blocked or not.

I removed that logic because the server's /inbox/$userId endpoint returns relations: (inward: null, outward: null) even after blocking so checking inward == false or outward == false would never be true. The original check was effectively dead code. To get the actual blocking status I call getUser() instead, which correctly returns blocking: true when a user is blocked.

I agree that tests would be valuable here to document which conversations are considered blocked and why. I will add those.