Open stanleyguevara opened 5 months ago
Hi 👋
So you mean you'd want the lib to not generate this?
public operator fun invoke(
title: String,
): Direction {
return Direction(
route = "$baseRoute" + "/${DestinationsStringNavType.serializeValue("title", title)}"
)
}
Rather to make it private, if navArgsDeletage
is defined.
Hi again, sorry for the big delay 🙏
I accept PRs if you want :) Given this is low priority, I'd really appreciate it!
HINT:
NavArgumentBridgeCodeBuilder#invokeMethodsCode
You can check this config and make the second method private if it is set.
For how configs are handled, check ConfigParser
.
And finally you may need to add CodeGenConfig
to the constructor of NavArgumentBridgeCodeBuilder
to be able to check it.
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 havingnavArgsDeletage
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 :)