Ribs: [Android][Question] Everyone (not just RIBs maintainers), when not to use RIBs?

[ericntd]

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 🙏

[ermik]

Half-system, where components are both RIBs and something else, is definitely not a good idea. RIBs implementation is _unopinionated_, in my opinion (no pun intended). If your UI is a tree-like hierarchy of ViewControllers (with a similar hierarchy in your data) whether they are colocated (complex views) or sequential (pages in the navigation stack), RIBs is a good base for enforcing separation of concerns and therefore ensuring modularity.

If your UI and / or your data is can not be represented as a _tree_ then RIBs are not for you. But then, you don't have to use RIBs in the entirety of your app, nor do you have to have a single tree. If there is a part of your app that matches tree requirement then you can use RIBs for that subsection of your project.

[ericntd]

Your reasoning makes sense.
However, I can't help but wonder "Aren't all apps in the world (and their data) representable as trees? 🤔 "

[ermik]

The reason why RIBs are such an interesting pattern is precisely because most systems are trivially hierarchical.