Codecov Report

Attention: Patch coverage is 71.42857% with 58 lines in your changes missing coverage. Please review.

Project coverage is 26.41%. Comparing base (60d46a3) to head (4c877ac).
Report is 4 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2345      +/-   ##
==========================================
+ Coverage   26.32%   26.41%   +0.09%     
==========================================
  Files         362      365       +3     
  Lines      136541   136701     +160     
==========================================
+ Hits        35940    36112     +172     
+ Misses     100601   100589      -12     

With the account repository merged and used everywhere, can we now take a look at this PR @Leptopoda?
I remember you said this would be perfect for the account repository. While I agree that most logic can be moved into it, I'm not sure how you want to tackle the problem of password confirmation having to interact with the UI.
The only way I'd see would be an async callback in the repository that is passed to it which allows triggering the password confirmation dialog.
I don't see another reasonable way to do this, other than using a callback or keeping the password confirmation logic entirely in the UI.
That said, other repositories will also need to be able to do password confirmations, so they'd either need to get the same callback or call the account repository to do it which might be a bit overkill if that is the only use of the account repository.

I don't think repositories should have any callbacks.
They can emit a stream of data the UI can subscribe to, but should never itself be able to call into UI code.

My Idea for this would be:

• have a bool validatePassword(String password) method in the AccountRepository. This would handle the API calls, error handling ...
• have a package:bloc bloc that handles the state of the UI element doing the password confirmation (text input, state handling ...). This will call into the account repo to do the actual validation
• have a UI component that handles the password confirmation flow (probably the dialog you've already built). The UI state (error message, submit buttons, loading UI) would be handled here.

Instead of the page view structure we have for pages, I'd create a class MyCoolDialog
that handles the bloc insertion using a provider (similar to the page), and a MyCoolDialogView that handles the ui itself (similar to the view). Depending on their size they can both live in a single file (unlike the pages and views that I prefer separated). The same file can then also contain a showMyCoolDialog method that calls showDialog underneath.