LemmyNet / LemmyNet/jerboa

Only pass in view models for screens for writable cases. If its read-only, just pass in the object.

Open
#2,174 2 comments 0 reactions 0 assignees View on GitHub

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

On many of the screens, we pass in large view models, which let you refetch and update data. For example, we pass in the siteViewModel, appSettingsViewModel, and accountViewModel into screens where it shouldn't need to write or update those objects, only read them.

This isn't ideal because:

  • It exposes the objects within as writeable, where many shouldn't be.
  • We then have to observeAsState, whereas in most cases we should only need to have the GetSiteResponse or AppSettings

We should go through every screen in MainActivity.kt, and make sure its only passing the minimum of what it needs.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in MainActivity.kt and review each screen's parameters, especially uses of siteViewModel, appSettingsViewModel, and accountViewModel. Identify screens that only read data and determine the smallest read-only values they need instead of writable view models. Done means every screen receives only the minimum required data while writable cases retain the needed update access.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.