joreilly / joreilly/MortyComposeKMM
[question] Domain objects based on GraphQL types
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 406
- Forks
- 27
- Avg merge
- 6d 11h
- Merged PRs (30d)
- 7
Description
Hi! First of all, thank you for this repo. I am exploring KMM + GraphQL and this was really helpful and inspirational.
Now the question: Do you think that having repositories and UI layer relying on GraphQL types instead of regular Kotlin data classes could have limitations at some point? There is always the possibility of writing Kotlin extensions if you need anything extra, but for annotations like @Serializable, it could be an overhead.
What's your opinion? If that is the case, I'm happy to work on a PR to showcase the domain classes and how I think the mapping can work between them.
Thank you!
Contributor guide
No contributing guide indexed for this repository
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
The issue does not mention files, tests, or an implementation entry point; start by clarifying whether a domain-model mapping example is wanted and which repository and UI layers it should cover. Define the expected scope and completion criteria before investigating a possible PR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, kotlin
- Domain
- api, mobile-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100