Update README.md

README.md

@@ -80,7 +80,7 @@ Now the IDE will even tell you the default arguments of the composable when call
 Notes about arguments:
 - They must be one of `String`, `Boolean`, `Int`, `Float`, `Long` to be considered navigation arguments.
   `NavController`, `NavBackStackEntry` or `ScaffoldState` (only if you are using `Scaffold`) can also be used by all destinations.
-- Navigation arguments' default values must be resolvable from the generated `DestinationSpec` class since the code written after the "`=`" 
+- Navigation arguments' default values must be resolvable from the generated `Destination` class since the code written after the "`=`" 
   will be copied into it as is. 
 Unfortunately, this means you won't be able to use a constant or a function call as the default value of a nav argument. However, if the parameter 
   type is not a navigation argument type, then everything is valid since it won't be considered a navigation argument of the destination.
@@ -154,13 +154,13 @@ sourceSets {
 
 ### Going deeper:
 
-- All annotated composables will generate an implementation of `DestinationSpec` which is a sealed interface that contains the full route, navigation arguments,
+- All annotated composables will generate an implementation of `Destination` which is a sealed interface that contains the full route, navigation arguments,
   `Content` composable function and the `withArgs` implementation.
-- `Scaffold` composable lambda parameters will be given a current `DestinationSpec`. This makes it trivial to have top bar, bottom bar and drawer depend on the current destination.
-- Besides the `NavHost` and `Scaffold` wrappers, the generated `Destinations` class contains a collection of all `DestinationSpec`s as well as the `startDestination`.
-- If you would like to have additional properties/functions in the `DestinationSpec` (for example a "title" which will be shown to the user for each screen) you can make an extension
-  property/function of `DestinationSpec`. Since it is a sealed interface, a `when` expression will make sure you always have a definition for each screen (check
-  `DestinationSpecExtensions.kt` file in the sample app).
+- `Destination` annotation can receive a `navGraph` parameter for nested navigation graphs. This will be the route of the nested graph and all destinations with the same `navGraph` will belong to it. If this parameter is not specified, then the `Destination` will belong to the root navigation graph (which is the norm when not using nested nav graphs)
+- `Scaffold` composable lambda parameters will be given a current `Destination`. This makes it trivial to have top bar, bottom bar and drawer depend on the current destination.
+- Besides the `NavHost` and `Scaffold` wrappers, the generated `Destinations` class contains all `NavGraphs`. Each `NavGraph` contains the start `Destination` as well as all its destinations and its nested `NavGraphs`.
+- If you would like to have additional properties/functions in the `Destination` (for example a "title" which will be shown to the user for each screen) you can make an extension
+  property/function of `Destination` for a similar effect. Since it is a sealed interface, a `when` expression will make sure you always have a definition for each screen (check this file for an example [file](https://github.com/raamcosta/compose-destinations/blob/main/app/src/main/java/com/ramcosta/samples/destinationstodosample/DestinationSpecExtensions.kt)).
 
 ### Current state