Change account verification flow to use simple `myUserInfo` to enable logged-in required items.
Open
Nobody has claimed this yet.
2 - low/medium priority
enhancement
- Dominant language
- Kotlin
- Stars
- 1.3k
- Forks
- 175
- Avg merge
- 6d 22h
- Merged PRs (30d)
- 9
Description
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 != nullto determine whether to enable or disable buttons, or hide them entirely. This simple check is how lemmy-ui handles all login-related items. - The
AccountViewModelshould probably take in themyUserInfoViewModelandsiteViewModelsas 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/Verifyingscreen, so that when switching accounts from the sidebar, the current screen doesn't need to take in and alter all these viewModels.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing account.doIfReadyElseDisplayInfo and the interactions among AccountViewModel, myUserInfoViewModel, and SiteViewModel/siteViewModels. Review how startup and account changes currently trigger verification and refetching. Done means logged-in actions can use myUserInfo for their state without each screen altering or resetting account-related view models.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- authentication, mobile
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100