Change account verification flow to use simple `myUserInfo` to enable logged-in required items.

[dessalines]

Pre-Flight checklist

• Did you check to see if this issue already exists?
• This is a single feature request. (Do not put multiple feature requests in one issue)
• This is not a question or discussion. (Use https://lemmy.ml/c/jerboa for that)

Describe The Feature Request Below

Nearly every lemmy API action which requires an account, is currently surrounded by:

account.doIfReadyElseDisplayInfo(
  appState,
  ctx,
  resources,
  snackbarHostState,
  scope,
  myUserInfoViewModel, (previously SiteViewModel)
  accountViewModel,
) {

• This account verification does a lot of altering and refetching of both the accountViewModel, and the Site/MyUserInfoViewModel, which is dangerous for screens which should not be changing accounts or resetting account info.
• Its cumbersome because now every screen requires many viewModels, which they should really only be reading.

Some recommendations:

• These checks should not really be done just to display or not display buttons, but should only be run on startup or account change.
• Buttons should use myUserInfo != null to determine whether to enable or disable buttons, or hide them entirely. This simple check is how lemmy-ui handles all login-related items.
• The AccountViewModel should probably take in the myUserInfoViewModel and siteViewModels as props, so that it can set them directly when switching accounts, rather than those viewmodels each using flows to watch the accountViewModel.
• It might be necessary to create a dedicated Logging In / Verifying screen, so that when switching accounts from the sidebar, the current screen doesn't need to take in and alter all these viewModels.

[MV-GH]

Ye, I am thinking about it now and account.doIfReadyElseDisplayInfo( on every button/action is too much friction.

Original that was because if it wasnt init and user did that action it was pretty much guaranteed to not succeed. It would inform and tell the user how to fix it.

But it could ve been implemented with much less friction. Listen to any 500, 401 and trigger background verification flow and let all those actions load / fail. It would just need a hook on each screen iso each action.

But maybe a "loading" screen might be better, it would have to include a login/ account switch plus some info with what is "loading" so that user stays informed on why its loading slow (instance might be slow). The verification stuff could be moved to there. And have generic background API stuff that listens to 401/500 to invalidate and trigger that flow. And prob current version. Also properly allowing it to block loading accounts for instances that aren't supported. (too old or new version) bc currently i assume they be seeing errors everywhere and only when they login again it would say unsupported version.

It would allow to guarantee in the screens that the LemmyApi instance is init. thus all those null checks can be removed. No suspend for to retrieve an lemmyApi instance.