diff --git a/documentation/components/backstack.md b/documentation/2.x/components/backstack.md similarity index 100% rename from documentation/components/backstack.md rename to documentation/2.x/components/backstack.md diff --git a/documentation/components/experimental.md b/documentation/2.x/components/experimental.md similarity index 100% rename from documentation/components/experimental.md rename to documentation/2.x/components/experimental.md diff --git a/documentation/components/index.md b/documentation/2.x/components/index.md similarity index 100% rename from documentation/components/index.md rename to documentation/2.x/components/index.md diff --git a/documentation/components/spotlight.md b/documentation/2.x/components/spotlight.md similarity index 100% rename from documentation/components/spotlight.md rename to documentation/2.x/components/spotlight.md diff --git a/documentation/faq.md b/documentation/2.x/faq.md similarity index 100% rename from documentation/faq.md rename to documentation/2.x/faq.md diff --git a/documentation/index_2.x.md b/documentation/2.x/index_2.x.md similarity index 97% rename from documentation/index_2.x.md rename to documentation/2.x/index_2.x.md index 51b9733fb..47a423dd2 100644 --- a/documentation/index_2.x.md +++ b/documentation/2.x/index_2.x.md @@ -119,12 +119,12 @@ Stacks, custom pagers, custom UI components – whether for navigation, or stand ## 2.x migration guide -If you used Appyx `1.x` before, you can find a [summary of differences](2.x/migrationguide.md) here. +If you used Appyx `1.x` before, you can find a [summary of differences](migrationguide.md) here. ## 1.x documentation This page is about Appyx `2.x` (alpha). -You can find `1.x` related documentation [here](1.x/index.md). +You can find `1.x` related documentation [here](../1.x/index.md). diff --git a/documentation/interactions/appyxcomponent.md b/documentation/2.x/interactions/appyxcomponent.md similarity index 100% rename from documentation/interactions/appyxcomponent.md rename to documentation/2.x/interactions/appyxcomponent.md diff --git a/documentation/interactions/gestures.md b/documentation/2.x/interactions/gestures.md similarity index 100% rename from documentation/interactions/gestures.md rename to documentation/2.x/interactions/gestures.md diff --git a/documentation/interactions/index.md b/documentation/2.x/interactions/index.md similarity index 100% rename from documentation/interactions/index.md rename to documentation/2.x/interactions/index.md diff --git a/documentation/interactions/ksp.md b/documentation/2.x/interactions/ksp.md similarity index 100% rename from documentation/interactions/ksp.md rename to documentation/2.x/interactions/ksp.md diff --git a/documentation/interactions/operations.md b/documentation/2.x/interactions/operations.md similarity index 100% rename from documentation/interactions/operations.md rename to documentation/2.x/interactions/operations.md diff --git a/documentation/interactions/transitionmodel.md b/documentation/2.x/interactions/transitionmodel.md similarity index 100% rename from documentation/interactions/transitionmodel.md rename to documentation/2.x/interactions/transitionmodel.md diff --git a/documentation/interactions/ui-representation.md b/documentation/2.x/interactions/ui-representation.md similarity index 100% rename from documentation/interactions/ui-representation.md rename to documentation/2.x/interactions/ui-representation.md diff --git a/documentation/interactions/usage.md b/documentation/2.x/interactions/usage.md similarity index 100% rename from documentation/interactions/usage.md rename to documentation/2.x/interactions/usage.md diff --git a/documentation/2.x/migrationguide.md b/documentation/2.x/migrationguide.md index 3501b1a5c..90b99c728 100644 --- a/documentation/2.x/migrationguide.md +++ b/documentation/2.x/migrationguide.md @@ -21,7 +21,7 @@ The library is packaged as multiple artifacts. - Android library - Compose Multiplatform. -Check also [Multiplatform](../navigation/multiplatform.md) documentation and the `:demos:appyx-navigation` module for code examples. +Check also [Multiplatform](navigation/multiplatform.md) documentation and the `:demos:appyx-navigation` module for code examples. #### :appyx-interactions @@ -52,7 +52,7 @@ Check also [Multiplatform](../navigation/multiplatform.md) documentation and the #### Core -Note that [BackStack](../components/backstack.md) and [Spotlight](../components/spotlight.md) are now standalone artifacts. Check your usage, you might only need `backstack`: +Note that [BackStack](components/backstack.md) and [Spotlight](components/spotlight.md) are now standalone artifacts. Check your usage, you might only need `backstack`: ```diff -implementation("com.bumble.appyx:core:1.x.x") diff --git a/documentation/navigation/concepts/composable-navigation.md b/documentation/2.x/navigation/concepts/composable-navigation.md similarity index 97% rename from documentation/navigation/concepts/composable-navigation.md rename to documentation/2.x/navigation/concepts/composable-navigation.md index 1f99e7869..0f4e562dc 100644 --- a/documentation/navigation/concepts/composable-navigation.md +++ b/documentation/2.x/navigation/concepts/composable-navigation.md @@ -1,88 +1,88 @@ ---- -title: Appyx Navigation – Composable navigation ---- - -# Composable navigation - -[AppyxComponents](../../components/index.md) in Appyx are composable. - -As a single `AppyxComponent` won't be enough for the whole of your whole app, you can use many in a composable way. That is, any managed element of a `AppyxComponent` can also host its own `AppyxComponent`. - - -## Nodes – structural elements for composing navigation - -```Nodes``` are the main structural element in Appyx. They can form a tree. - -You can think of a `Node` as a standalone unit of your app with: - -- Its own `AppyxComponent` -- Its own [Lifecycle](../features/lifecycle.md) -- State restoration -- A `@Composable` view -- Business logic that's kept alive even when the view isn't added to the composition -- The ability to host generic [Plugins](../features/plugins.md) to extract extra concerns without enforcing any particular architectural pattern - -This allows you to make your app's business logic also composable by leveraging `Nodes` as lifecycled components. - - -## Parent nodes, child nodes - -`Nodes` can have other `Nodes` as children. This means you can represent your whole application as a tree of Appyx nodes. - - - -You can go as granular or as high-level as it fits you. This allows to keep the complexity low in individual `Nodes` by extracting responsibilities to children, as well as composing other components to build more complex functionality. - - -## ChildAware API - -A `Node` can react to dynamically added child `Nodes` in the tree: [ChildAware API](../features/childaware.md) - - -## Navigation in the tree - - - -Once you've structured your navigation in a composable way, you can add an `AppyxComponent` to a `Node` of this tree and make it dynamic: - -- Some parts in this tree are active while others ore not -- The active parts define what state the application is in, and what the user sees on the screen -- We can change what's active by using an `AppyxComponent` on each level of the tree -- Changes will feel like navigation to the user - -See [Implicit navigation](implicit-navigation.md) and [Explicit navigation](explicit-navigation.md) for building complex navigation behaviours with this approach. - - - -## How AppyxComponents affect Nodes - -`AppyxComponent` operations will typically result in: - -- Adding or removing child `Nodes` of a `Node` -- Move them on and off the screen -- Change their states - -As an illustration: - - - -Here: - -- `Back stack` illustrates adding and removing child `Nodes` -- `Tiles` illustrates changing the state of children and removing them from the `Node` - -These are just two examples, you're of course not limited to using them. - - - -## Summary - -A summary of Appyx's approach to structuring applications: - -- Compose your app out of `Nodes` with their own lifecycles and state -- Navigation is local, composed of individual pieces of `AppyxComponents` -- Navigation is stateful -- Navigation is unit-testable -- Nested navigation and multi-module navigation works as a default -- You're free to implement your own navigable components by utilising `AppyxComponents` -- Avoid global navigation concerns, like shared modules needing to know about the application, or the application needing to know about all its possible modules +--- +title: Appyx Navigation – Composable navigation +--- + +# Composable navigation + +[AppyxComponents](../../components/index.md) in Appyx are composable. + +As a single `AppyxComponent` won't be enough for the whole of your whole app, you can use many in a composable way. That is, any managed element of a `AppyxComponent` can also host its own `AppyxComponent`. + + +## Nodes – structural elements for composing navigation + +```Nodes``` are the main structural element in Appyx. They can form a tree. + +You can think of a `Node` as a standalone unit of your app with: + +- Its own `AppyxComponent` +- Its own [Lifecycle](../features/lifecycle.md) +- State restoration +- A `@Composable` view +- Business logic that's kept alive even when the view isn't added to the composition +- The ability to host generic [Plugins](../features/plugins.md) to extract extra concerns without enforcing any particular architectural pattern + +This allows you to make your app's business logic also composable by leveraging `Nodes` as lifecycled components. + + +## Parent nodes, child nodes + +`Nodes` can have other `Nodes` as children. This means you can represent your whole application as a tree of Appyx nodes. + + + +You can go as granular or as high-level as it fits you. This allows to keep the complexity low in individual `Nodes` by extracting responsibilities to children, as well as composing other components to build more complex functionality. + + +## ChildAware API + +A `Node` can react to dynamically added child `Nodes` in the tree: [ChildAware API](../features/childaware.md) + + +## Navigation in the tree + + + +Once you've structured your navigation in a composable way, you can add an `AppyxComponent` to a `Node` of this tree and make it dynamic: + +- Some parts in this tree are active while others ore not +- The active parts define what state the application is in, and what the user sees on the screen +- We can change what's active by using an `AppyxComponent` on each level of the tree +- Changes will feel like navigation to the user + +See [Implicit navigation](implicit-navigation.md) and [Explicit navigation](explicit-navigation.md) for building complex navigation behaviours with this approach. + + + +## How AppyxComponents affect Nodes + +`AppyxComponent` operations will typically result in: + +- Adding or removing child `Nodes` of a `Node` +- Move them on and off the screen +- Change their states + +As an illustration: + + + +Here: + +- `Back stack` illustrates adding and removing child `Nodes` +- `Tiles` illustrates changing the state of children and removing them from the `Node` + +These are just two examples, you're of course not limited to using them. + + + +## Summary + +A summary of Appyx's approach to structuring applications: + +- Compose your app out of `Nodes` with their own lifecycles and state +- Navigation is local, composed of individual pieces of `AppyxComponents` +- Navigation is stateful +- Navigation is unit-testable +- Nested navigation and multi-module navigation works as a default +- You're free to implement your own navigable components by utilising `AppyxComponents` +- Avoid global navigation concerns, like shared modules needing to know about the application, or the application needing to know about all its possible modules diff --git a/documentation/navigation/concepts/explicit-navigation.md b/documentation/2.x/navigation/concepts/explicit-navigation.md similarity index 96% rename from documentation/navigation/concepts/explicit-navigation.md rename to documentation/2.x/navigation/concepts/explicit-navigation.md index 7b1bb8edf..b9ef884a9 100644 --- a/documentation/navigation/concepts/explicit-navigation.md +++ b/documentation/2.x/navigation/concepts/explicit-navigation.md @@ -1,213 +1,213 @@ ---- -title: Appyx Navigation – Explicit navigation ---- - -# Explicit navigation - -When [Implicit navigation](implicit-navigation.md) doesn't fit your use case, you can try an explicit approach. - -!!! info "Relevant methods" - - - Node.attachChild() - - Node.waitForChildAttached() - -Using these methods we can chain together a path which leads from the root of the tree to a specific `Node`. - -## Use case - -We want to navigate from `Chat` - - - -to onboarding's first screen `O1`: - - - -This time we'll want to do this explicitly by calling a function. - - -## The plan - -1. Create a public method on `Root` that attaches `Onboarding` -2. Create a public method on `Onboarding` that attaches the first onboarding screen -3. Create a `Navigator`, that starting from an instance of `Root`, can chain these public methods together into a single action: `navigateToO1()` -4. Capture an instance of `Root` to use with `Navigator` -5. Call `navigateToO1()` on our `Navigator` instance - - -## Step 1 – `Root` → `Onboarding` - -First, we need to define how to programmatically attach `Onboarding` to the `Root`: - -```kotlin -class RootNode( - nodeContext: NodeContext, - backStack: BackStack -) : Node( - nodeContext = nodeContext, - appyxComponent = backStack, -) { - - suspend fun attachOnboarding(): OnboardingNode { - return attachChild { - backStack.replace(NavTarget.Onboarding) - } - } -} -``` - -Let's break down what happens here: - -1. Since `attachChild` has a generic `` return type, it will conform to the defined `OnboardingNode` type -2. However, `attachChild` doesn't know how to create navigation to `OnboardingNode` – that's something only we can do with the provided lambda -3. We replace `NavTarget.Onboarding` into the back stack -4. Doing this _should_ result in `OnboardingNode` being created and added to `RootNode` as a child -5. `attachChild` expects an instance of `OnboardingNode` to appear as a child of `Root` as a consequence of executing our lambda -6. Once it appears, `attachChild` returns it - - -!!! info "Important" - - It's our responsibility to make sure that the provided lambda actually results in the expected child being added. If we accidentally do something else instead, for example: - - ```kotlin - suspend fun attachOnboarding(): OnboardingNode { - return attachChild { - backStack.replace(NavTarget.Main) // Wrong NavTarget - } - } - ``` - - Then an exception will be thrown after a timeout. - - -## Step 2 – `Onboarding` → `O1` - -Unlike `Root`, `Onboarding` uses [Spotlight](../../components/spotlight.md) instead of [BackStack](../../components/backstack.md) as an `AppyxComponent`, so navigation to the first screen is slightly different: - -```kotlin -class OnboardingNode( - nodeContext: NodeContext, - spotlight: Spotlight -) : Node( - nodeContext = nodeContext, - appyxComponent = spotlight, -) { - - suspend fun attachO1(): O1Node { - return attachChild { - spotlight.activate(index = 0) - } - } -} -``` - - -## Step 3 – Our `Navigator` - -```kotlin -interface Navigator { - fun navigateToO1() -} -``` - -In this case we'll implement it directly with our activity: - -```kotlin -class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { - - lateinit var rootNode: RootNode // See the next step - - override fun navigateToO1() { - lifecycleScope.launch { - rootNode - .attachOnboarding() - .attachO1() - } - } -} -``` - -## Step 4 – An instance of `RootNode` - -As the last piece of the puzzle, we'll also need to capture the instance of `RootNode` to make it all work. We can do that by a `NodeReadyObserver` plugin when setting up our tree: - - -```kotlin -class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { - - lateinit var rootNode: RootNode - - override fun navigateToO1() { /*...*/ } - - override fun onCreate(savedInstanceState: Bundle?) { - super.onCreate(savedInstanceState) - setContent { - NodeHost(integrationPoint = appyxIntegrationPoint) { - RootNode( - nodeContext = it, - navigator = this@ExplicitNavigationExampleActivity, - plugins = listOf(object : NodeReadyObserver { - override fun init(node: RootNode) { - rootNode = node - } - }) - ) - } - } - } -} -``` - -## Step 5 – Using the `Navigator` - -See how in the previous snippet `RootNode` receives a `navigator` dependency. - -It can pass it further down the tree as a dependency to other nodes. Those nodes can call the methods of the `Navigator`, which will change the global navigation state directly. - - ---- - -## Bonus: Wait for a child to be attached - -There might be cases when we want to wait for a certain action to be _performed by the user_, rather than us, to result in a child being attached. - -In these cases we can use `Node.waitForChildAttached()` instead. - - -### Use case – Wait for login - -A typical case building an explicit navigation chain that relies on `Logged in` being attached. Most probably `Logged in` has a dependency on some kind of a `User` object. Here we want to wait for the user to authenticate themselves, rather than creating a dummy user object ourselves. - - -```kotlin -class RootNode( - nodeContext: NodeContext, -) : Node( - nodeContext = nodeContext -) { - - suspend fun waitForLoggedIn(): LoggedInNode = - waitForChildAttached() -} -``` - -This method will wait for `LoggedInNode` to appear in the child list of `RootNode` and return with it. If it's already there, it returns immediately. - -A navigation chain using it could look like: - -```kotlin -class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { - - override fun navigateToProfile() { - lifecycleScope.launch { - rootNode - .waitForLoggedIn() - .attachMain() - .attachProfile() - } - } -} -``` - -You can find related code examples in `ExplicitNavigationExampleActivity` in our samples. +--- +title: Appyx Navigation – Explicit navigation +--- + +# Explicit navigation + +When [Implicit navigation](implicit-navigation.md) doesn't fit your use case, you can try an explicit approach. + +!!! info "Relevant methods" + + - Node.attachChild() + - Node.waitForChildAttached() + +Using these methods we can chain together a path which leads from the root of the tree to a specific `Node`. + +## Use case + +We want to navigate from `Chat` + + + +to onboarding's first screen `O1`: + + + +This time we'll want to do this explicitly by calling a function. + + +## The plan + +1. Create a public method on `Root` that attaches `Onboarding` +2. Create a public method on `Onboarding` that attaches the first onboarding screen +3. Create a `Navigator`, that starting from an instance of `Root`, can chain these public methods together into a single action: `navigateToO1()` +4. Capture an instance of `Root` to use with `Navigator` +5. Call `navigateToO1()` on our `Navigator` instance + + +## Step 1 – `Root` → `Onboarding` + +First, we need to define how to programmatically attach `Onboarding` to the `Root`: + +```kotlin +class RootNode( + nodeContext: NodeContext, + backStack: BackStack +) : Node( + nodeContext = nodeContext, + appyxComponent = backStack, +) { + + suspend fun attachOnboarding(): OnboardingNode { + return attachChild { + backStack.replace(NavTarget.Onboarding) + } + } +} +``` + +Let's break down what happens here: + +1. Since `attachChild` has a generic `` return type, it will conform to the defined `OnboardingNode` type +2. However, `attachChild` doesn't know how to create navigation to `OnboardingNode` – that's something only we can do with the provided lambda +3. We replace `NavTarget.Onboarding` into the back stack +4. Doing this _should_ result in `OnboardingNode` being created and added to `RootNode` as a child +5. `attachChild` expects an instance of `OnboardingNode` to appear as a child of `Root` as a consequence of executing our lambda +6. Once it appears, `attachChild` returns it + + +!!! info "Important" + + It's our responsibility to make sure that the provided lambda actually results in the expected child being added. If we accidentally do something else instead, for example: + + ```kotlin + suspend fun attachOnboarding(): OnboardingNode { + return attachChild { + backStack.replace(NavTarget.Main) // Wrong NavTarget + } + } + ``` + + Then an exception will be thrown after a timeout. + + +## Step 2 – `Onboarding` → `O1` + +Unlike `Root`, `Onboarding` uses [Spotlight](../../components/spotlight.md) instead of [BackStack](../../components/backstack.md) as an `AppyxComponent`, so navigation to the first screen is slightly different: + +```kotlin +class OnboardingNode( + nodeContext: NodeContext, + spotlight: Spotlight +) : Node( + nodeContext = nodeContext, + appyxComponent = spotlight, +) { + + suspend fun attachO1(): O1Node { + return attachChild { + spotlight.activate(index = 0) + } + } +} +``` + + +## Step 3 – Our `Navigator` + +```kotlin +interface Navigator { + fun navigateToO1() +} +``` + +In this case we'll implement it directly with our activity: + +```kotlin +class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { + + lateinit var rootNode: RootNode // See the next step + + override fun navigateToO1() { + lifecycleScope.launch { + rootNode + .attachOnboarding() + .attachO1() + } + } +} +``` + +## Step 4 – An instance of `RootNode` + +As the last piece of the puzzle, we'll also need to capture the instance of `RootNode` to make it all work. We can do that by a `NodeReadyObserver` plugin when setting up our tree: + + +```kotlin +class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { + + lateinit var rootNode: RootNode + + override fun navigateToO1() { /*...*/ } + + override fun onCreate(savedInstanceState: Bundle?) { + super.onCreate(savedInstanceState) + setContent { + NodeHost(integrationPoint = appyxIntegrationPoint) { + RootNode( + nodeContext = it, + navigator = this@ExplicitNavigationExampleActivity, + plugins = listOf(object : NodeReadyObserver { + override fun init(node: RootNode) { + rootNode = node + } + }) + ) + } + } + } +} +``` + +## Step 5 – Using the `Navigator` + +See how in the previous snippet `RootNode` receives a `navigator` dependency. + +It can pass it further down the tree as a dependency to other nodes. Those nodes can call the methods of the `Navigator`, which will change the global navigation state directly. + + +--- + +## Bonus: Wait for a child to be attached + +There might be cases when we want to wait for a certain action to be _performed by the user_, rather than us, to result in a child being attached. + +In these cases we can use `Node.waitForChildAttached()` instead. + + +### Use case – Wait for login + +A typical case building an explicit navigation chain that relies on `Logged in` being attached. Most probably `Logged in` has a dependency on some kind of a `User` object. Here we want to wait for the user to authenticate themselves, rather than creating a dummy user object ourselves. + + +```kotlin +class RootNode( + nodeContext: NodeContext, +) : Node( + nodeContext = nodeContext +) { + + suspend fun waitForLoggedIn(): LoggedInNode = + waitForChildAttached() +} +``` + +This method will wait for `LoggedInNode` to appear in the child list of `RootNode` and return with it. If it's already there, it returns immediately. + +A navigation chain using it could look like: + +```kotlin +class ExplicitNavigationExampleActivity : NodeActivity(), Navigator { + + override fun navigateToProfile() { + lifecycleScope.launch { + rootNode + .waitForLoggedIn() + .attachMain() + .attachProfile() + } + } +} +``` + +You can find related code examples in `ExplicitNavigationExampleActivity` in our samples. diff --git a/documentation/navigation/concepts/implicit-navigation.md b/documentation/2.x/navigation/concepts/implicit-navigation.md similarity index 100% rename from documentation/navigation/concepts/implicit-navigation.md rename to documentation/2.x/navigation/concepts/implicit-navigation.md diff --git a/documentation/navigation/concepts/model-driven-navigation.md b/documentation/2.x/navigation/concepts/model-driven-navigation.md similarity index 100% rename from documentation/navigation/concepts/model-driven-navigation.md rename to documentation/2.x/navigation/concepts/model-driven-navigation.md diff --git a/documentation/navigation/features/childaware.md b/documentation/2.x/navigation/features/childaware.md similarity index 100% rename from documentation/navigation/features/childaware.md rename to documentation/2.x/navigation/features/childaware.md diff --git a/documentation/navigation/features/deep-linking.md b/documentation/2.x/navigation/features/deep-linking.md similarity index 100% rename from documentation/navigation/features/deep-linking.md rename to documentation/2.x/navigation/features/deep-linking.md diff --git a/documentation/navigation/features/lifecycle.md b/documentation/2.x/navigation/features/lifecycle.md similarity index 100% rename from documentation/navigation/features/lifecycle.md rename to documentation/2.x/navigation/features/lifecycle.md diff --git a/documentation/navigation/features/material3.md b/documentation/2.x/navigation/features/material3.md similarity index 100% rename from documentation/navigation/features/material3.md rename to documentation/2.x/navigation/features/material3.md diff --git a/documentation/navigation/features/plugins.md b/documentation/2.x/navigation/features/plugins.md similarity index 100% rename from documentation/navigation/features/plugins.md rename to documentation/2.x/navigation/features/plugins.md diff --git a/documentation/navigation/features/scoped-di.md b/documentation/2.x/navigation/features/scoped-di.md similarity index 100% rename from documentation/navigation/features/scoped-di.md rename to documentation/2.x/navigation/features/scoped-di.md diff --git a/documentation/navigation/features/surviving-configuration-changes.md b/documentation/2.x/navigation/features/surviving-configuration-changes.md similarity index 100% rename from documentation/navigation/features/surviving-configuration-changes.md rename to documentation/2.x/navigation/features/surviving-configuration-changes.md diff --git a/documentation/navigation/index.md b/documentation/2.x/navigation/index.md similarity index 100% rename from documentation/navigation/index.md rename to documentation/2.x/navigation/index.md diff --git a/documentation/navigation/integrations/compose-navigation.md b/documentation/2.x/navigation/integrations/compose-navigation.md similarity index 100% rename from documentation/navigation/integrations/compose-navigation.md rename to documentation/2.x/navigation/integrations/compose-navigation.md diff --git a/documentation/navigation/integrations/di-frameworks.md b/documentation/2.x/navigation/integrations/di-frameworks.md similarity index 100% rename from documentation/navigation/integrations/di-frameworks.md rename to documentation/2.x/navigation/integrations/di-frameworks.md diff --git a/documentation/navigation/integrations/ribs.md b/documentation/2.x/navigation/integrations/ribs.md similarity index 100% rename from documentation/navigation/integrations/ribs.md rename to documentation/2.x/navigation/integrations/ribs.md diff --git a/documentation/navigation/integrations/rx.md b/documentation/2.x/navigation/integrations/rx.md similarity index 100% rename from documentation/navigation/integrations/rx.md rename to documentation/2.x/navigation/integrations/rx.md diff --git a/documentation/navigation/integrations/viewmodel.md b/documentation/2.x/navigation/integrations/viewmodel.md similarity index 100% rename from documentation/navigation/integrations/viewmodel.md rename to documentation/2.x/navigation/integrations/viewmodel.md diff --git a/documentation/navigation/multiplatform.md b/documentation/2.x/navigation/multiplatform.md similarity index 100% rename from documentation/navigation/multiplatform.md rename to documentation/2.x/navigation/multiplatform.md diff --git a/documentation/navigation/quick-start.md b/documentation/2.x/navigation/quick-start.md similarity index 100% rename from documentation/navigation/quick-start.md rename to documentation/2.x/navigation/quick-start.md diff --git a/documentation/navigation/sample-app.md b/documentation/2.x/navigation/sample-app.md similarity index 100% rename from documentation/navigation/sample-app.md rename to documentation/2.x/navigation/sample-app.md diff --git a/documentation/releases/2.0.0-alpha10.md b/documentation/2.x/releases/2.0.0-alpha10.md similarity index 100% rename from documentation/releases/2.0.0-alpha10.md rename to documentation/2.x/releases/2.0.0-alpha10.md diff --git a/documentation/releases/2.0.0.md b/documentation/2.x/releases/2.0.0.md similarity index 100% rename from documentation/releases/2.0.0.md rename to documentation/2.x/releases/2.0.0.md diff --git a/documentation/releases/changelog.md b/documentation/2.x/releases/changelog.md similarity index 100% rename from documentation/releases/changelog.md rename to documentation/2.x/releases/changelog.md diff --git a/documentation/releases/downloads.md b/documentation/2.x/releases/downloads.md similarity index 100% rename from documentation/releases/downloads.md rename to documentation/2.x/releases/downloads.md