You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, this is rather just a loose idea for improvement, maybe something for 2.0
I think having two equivalent operator fun invoke to navigate to the same destination can be somewhat undesired.
When having navArgsDeletage this is generated:
I've found our team is using almost exclusively navArgsDelegate version because click-through-ability is way better.
If I need to see "who navigates to this screen?" I can just ctrl+clik its arguments, no need to go through generated class.
It still happens once i a while somebody uses the wrong option, would be nice to be able to block that.
Which would simply make the basic invoke private, if there's navArgsDelegate used.
Let me know what you think. I can do a PR on it if you see no issues with such approach :)
The text was updated successfully, but these errors were encountered:
Hello, this is rather just a loose idea for improvement, maybe something for 2.0
I think having two equivalent
operator fun invoke
to navigate to the same destination can be somewhat undesired.When having
navArgsDeletage
this is generated:I've found our team is using almost exclusively
navArgsDelegate
version because click-through-ability is way better.If I need to see "who navigates to this screen?" I can just ctrl+clik its arguments, no need to go through generated class.
It still happens once i a while somebody uses the wrong option, would be nice to be able to block that.
It could be done by something like:
Which would simply make the basic invoke private, if there's
navArgsDelegate
used.Let me know what you think. I can do a PR on it if you see no issues with such approach :)
The text was updated successfully, but these errors were encountered: