Update composeDestinations to v2.1.0-beta11

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
io.github.raamcosta.compose-destinations:ksp	2.1.0-beta09 -> 2.1.0-beta11
io.github.raamcosta.compose-destinations:core	2.1.0-beta09 -> 2.1.0-beta11

---

Release Notes

raamcosta/compose-destinations (io.github.raamcosta.compose-destinations:ksp)

v2.1.0-beta11

Compare Source

Changes

• Fixes #​668
• Updated dependencies (official navigation to 2.8.0-beta06)
• Check release notes of previous release if you're coming from beta09 or below

Full Changelog: raamcosta/compose-destinations@2.1.0-beta10...2.1.0-beta11

v2.1.0-beta10

Compare Source

Changes

• DestinationsNavHost start destination can now also have mandatory navigation arguments! 🙌
  • ⚠️ Small breaking change, rename startRoute to start, for more, read below 👇
• Result back feature now supports all types that normal navigation supports! 🚀
• Dependencies update - (navigation now used is 2.8.0-beta05)
• New debug mode
• Fixes #​653
• Fixes #​661 (related with NavHost now accepting initial nav arguments)
• Small improvements

DestinationsNavHost start destination can now also have mandatory navigation arguments! 🙌

If you were passing a startRoute parameter when calling DestinationsNavHost, you'll now need to update it to just start and the parameter type is now a Direction (same type navigate method receives). So you can pass arguments here, like:

DestinationsNavHost(
    start = MyStartDestination(someArgs),
    // ....
)

Besides, in order for Compose Destinations to be sure you won't get a runtime exception, if your start route has mandatory arguments, then you'll need to either make them non mandatory (by adding defaults to them or making them null), or if you don't want to do that (let's say that Destination is also navigated to in a lot of other places, and the defaults in those cases are not ideal), you can:

@&#8203;NavHostDefaultStartArgs<RootGraph> // for a RootGraph which has a ...
val defaultRootStartArgs = GreetingScreenNavArgs( //  ...`GreetingScreen` has its start destination, with `GreetingScreenNavArgs`
    strArgument = "oneArgument",
    idArgument = 0
)

These arguments will be automatically "sent" to GreetingScreenDestination (taking the above example) when the NavHost is first called!

Result back feature now supports all types that normal navigation supports! 🚀

Previously, only these result types were allowed:

• String, Boolean, Float, Int, Long, Serializable, or Parcelable.
• Type cannot have type arguments itself (f.e you can't use Array even though it is Serializable)

Now it allows all of these (same as normal navigation):

• String
• Boolean
• Int
• Long
• Float
• Parcelable
• Serializable
• Enums
• @​kotlinx.serialization.Serializable annotated types
• Custom navigation types (Types for which the user has defined a serialization to and from string)
• Array and ArrayList of the above types

For Boolean, Int, Float, Long, you'll need to use BooleanArray, IntArray, FloatArray, LongArray instead of Array, Array, Array, Array.

⚠️ If you were manually calling a Composable Destination which receives either a ResultBackNavigator or a ResultRecipient you will need to update those calls to pass in a DestinationsNavType corresponding to your result type.
You can check the corresponding generated Destination and see how it calls your Composable, and do the same, or you can just start typing your result class type name (lower case) and IDE will help you.

For example, if your Destination receives a:

• ResultBackNavigator<Boolean> you'll want to pass in resultBackNavigator(booleanNavType) (booleanNavType is a top level field you can import from core library)
• ResultBackNavigator<MyParcelableClass> you'll pass resultBackNavigator(myParcelableClassNavType) (myParcelableClassNavType is a top level field you can import from generated code).

If not calling it manually, then generated code will do this for you, so no need to change anything in that case.

New debug mode

This is mainly to help me understand users' setup when there's a reported issue so that I can find the root cause and fix it quicker.
New ksp configuration added:

ksp {
    arg("compose-destinations.debugMode", "$rootDir")
}

When set, it will write some debug files to a folder on $rootDir/composeDestinationsDebug (taking above example).
Please make sure to:

• add this configuration for all modules that use compose destinations ksp
• do ./gradle clean and delete previous debug folder
• run the app or build the project
• share the files with me somehow (ex: through the github issue, DM on Kotlin slack, etc).
• remove the configuration and delete the debug folder
  DO NOT leave the configuration ON as it may slow down builds for no reason, just remove it after sending me the files.

Full Changelog: raamcosta/compose-destinations@2.1.0-beta09...2.1.0-beta10

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.