[Android][Question] Everyone (not just RIBs maintainers), when not to use RIBs?
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 7.9k
- Forks
- 914
- PR merge metrics
- No merged PRs in 30d
Description
I found the use of Dagger's Dependent Components (enforced by RIBs; as opposed to Sub-Components) complex and unnecessary for many screens in my app.
Also, the Dagger syntax RIBs are using are more verbose and complex than dagger-android
I have a feeling RIBs is suitable for complex screens with deeply nested views and/ or child views vary greatly depending on the user's state and/ or the wide variety of A/ B testing and feature flags
So I wonder when and where is good to use RIBs? When is it better to use MVVM + dagger-android + Dagger's Sub-components.
Does a hybrid-system (half RIBs and half not) make sense at all?
🤔
Hope anyone can share there experimenting migrating in and out of RIBs 🙏
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
The issue names no files, tests, or entry points. Start by examining the RIBs, MVVM, dagger-android, and Dagger component tradeoffs described here; done would be documented guidance on when to use RIBs, when to use the alternatives, and whether a hybrid system is appropriate.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100