Hello! Anyone faced issue like this? I’m just starting to use decompose so it might be that I’m doing something wrong. I get this error when I try to build Android app, but iOS app builds and runs with same code in shared module.

e: /***/shared/src/commonMain/kotlin/*/*/*/root/RootComponent.kt: (38, 10): This class does not have a constructor

Line that reports is where I use

@Parcelize

annotation. I use latest version of decompose: 1.0.0-alpha-07-native-compose. I will share code in 🧵 ⬇️

Hey everyone! What's the recommended way of doing dynamic number of child components? Say I have a grid, that grid is one component, but then each item would be a separate component.

childContext

requires a key

String

which I don't have. Also the number of items in the grid is dynamic, there will be more and less during the lifetime of the grid component.

Trying to migrate to the new decompose API from

0.6.0

->

1.0.0-alpha07

but i'm unable resolve the references on Android Studio Electric Eel 2022.1.1 Beta 5. The build just works fine so Im pretty sure this is an IDE issue. Any known workarounds for this? Related to https://github.com/arkivanov/Decompose/issues/190 i think

Yeah, this is related to the newer Kotlin version and IDE issues. You can try different IDEs. Also you can try clean the project, delete .idea file, and reopen the project

I'm using the latest IDEA, works fine for me. I'm only getting unresolved Compose references in Android modules and androidMain source sets. But this is a bit different.

The first Beta version of Decompose is released -

1.0.0-beta-01

! - Added

SimpleNavigation

and exposed

SimpleChildNavState

for custom navigation implementations - Added main thread checks to

MutableValue

Provide old and new child stacks in

StackRouterView#children

function - Added

disableInputDuringAnimation

argument to

stackAnimation

function - Converted

StackAnimation

and

StackAnimator

interfaces to

fun

interfaces - Moved

StackNavigation

and

OverlayNavigation

factory functions next to the corresponding interfaces Please read the release notes - https://github.com/arkivanov/Decompose/releases/tag/1.0.0-beta-01

I have similar issue as mentioned in this message with `extensions-compose-jetbrains`: https://kotlinlang.slack.com/archives/C03H3N51SKT/p1668819580893639 But only when I build iOS app - either from Android Studio or from XCode. Do I maybe miss something? It doesn’t seem like same issue to me as this one since everything builds and works on Android but on iOS it fails when it tries to assemble shared module with same error. I will paste full error in 🧵.

Hi. Trying to migrate from

back-pressed

to

back-handler

api to enable predictive back for

jetbrains-compose

with the new

StackNavigation

. Previously (as of 0.6.0) we had to do

val LocalBackPressedHandler: ProvidableCompositionLocal<BackPressedHandler?> = staticCompositionLocalOf { null }

// On activity
val backPressedHandler = BackPressedHandler(onBackPressedDispatcher)

setContent {
  CompositionLocalProvider(LocalBackPressedHandler provides backPressedHandler) {
    ..
  }
}

is this no longer necessary given the

ChildStack

has a

handleBackButton

?

👋 i would like to use decompose stack router and was looking at how to make it work with different modules. Looks like alternatives such as the compose or flutter routers lean towards a uri based routing system. My idea is to use a config data class representing the route and then convert that to locations/destinations in the builder. Does this seem like a reasonable approach? Has anyone done something similar? Is this anyhow planned? The benefits i see are: • Implementing the web history or deeplinks would be trivial • Each module just needs to know the path, not any impl detail

[SOLVED] Greetings. Something weird is going on with my KMP project. I understand, it is in Alpha and all the stuff. This is "compose" module (doing the way it is done in

decompose

samples. Check this out, compiler complains, however build is OK and I actually can get the instance during runtime. The build.kts for this module is:

...
sourceSets {
    all {
      languageSettings.apply {
        optIn("kotlin.RequiresOptIn")
        optIn("kotlinx.coroutines.ExperimentalCoroutinesApi")
        optIn("org.jetbrains.compose.ExperimentalComposeLibrary")
      }
    }
    val androidMain by getting {
      dependencies {
        api("androidx.appcompat:appcompat:1.5.1")

        implementation("androidx.compose.material3:material3:1.1.0-alpha02")
        implementation("androidx.compose.material3:material3-window-size-class:1.1.0-alpha02")
      }
    }
    val commonMain by getting {
      dependencies {
        implementation(project(":shared"))

        api(compose.runtime)
        api(compose.foundation)
        @OptIn(org.jetbrains.compose.ExperimentalComposeLibrary::class)
        api(compose.material3)

        // Decompose
        implementation("com.arkivanov.decompose:decompose:1.0.0-beta-01")
        // Value<T>.subscribeAsState()
        implementation("com.arkivanov.decompose:extensions-compose-jetbrains:1.0.0-beta-01")
      }
    }
    val jvmMain by getting {
      dependencies {
        implementation(compose.desktop.currentOs)
      }
    }
  }
...

Decompose

1.0.0-beta-02

is released! - Added

minAlpha

argument to fade animator - Added a convenience overload function

ComponentContext#children

with

Parcelable

navigation state - Applied parcelize-darwin plugin, updated Essenty to

0.7.0

Release notes: https://github.com/arkivanov/Decompose/releases/tag/1.0.0-beta-02

@Arkadii Ivanov greetings. You do have

@Preview

annotation in

decompose

samples. Do they work actually, or is there any hack around KMP to use preview feature yet? Please, share.

Hi @Arkadii Ivanov. In my application i’m using the childstack backstack to display or not a back arrow in a top app bar. If i quickly switch of apps and come back, the backstack will be empty but the navbar backbutton will navigate back to the previous screen, which seems odd to me. Shouldn’t the backstack be in sync with the navigation upon restoration or is there something i’m missing ?

Ok i've got a mix of gradle version/multiplatform version/intelliJ version that is actually working, no one touch anything 😂 except after updating various things, my Android Module now thinks it doesn't have a compose runtime:

IncompatibleComposeRuntimeVersionException: The Compose Compiler requires the Compose Runtime to be on the class path, but none could be found. The compose compiler plugin you are using (version 1.3.2) expects a minimum runtime version of 1.0.0.

Anyone run into this before?

Decompose

1.0.0-beta-03

is released! - Added

backStackCreateDepth

argument to

Child Stack

- Added

persistent

argument to

Child Stack

- Updated Essenty to

0.8.0 (state preservation on JVM/desktop)

Release notes: https://github.com/arkivanov/Decompose/releases/tag/1.0.0-beta-03

hey what other stuff might you put in a Destination class other than the component it's self? All of mine so far are one to one, Destination -> Component

hello, decompose already support compose for ios???

huh you think I can bring in and start using the jetbrains compose 1.3.0 rc and decompose will be alright with it?

Anyone using Decompose + Compose Multiplatform + Koin combination? If so is there any way to inject decompose components directly into compose functions with Koin? I know there is a example of someting similar Arkadii did for Droidcon app, but there he passes components into compose functions. What I want is basically the same thing, but injecting components into functions instead of passing them. If I’m not mistaken Koin doesn’t support that for multiplatform compose, but did somebody tried to do something like that or has some workaround to do so? :thank-you:

Hi everyone, first of all thanks for the great effort and time invested in the Decompose library as I’m already enjoying the benefits it provides. Second, I’m currently using it in a Compose-Desktop application, and I’m in a situation where I need to launch a few coroutines but I’m a little bit confused as to how the

main

&

io

`CoroutineContext`s are defined. On the documentation page (https://arkivanov.github.io/Decompose/component/scopes/#creating-a-coroutinescope-in-a-component) I found following sample:

fun CoroutineScope(context: CoroutineContext, lifecycle: Lifecycle): CoroutineScope {
    val scope = CoroutineScope(context)
    lifecycle.doOnDestroy(scope::cancel)
    return scope
}

fun LifecycleOwner.coroutineScope(context: CoroutineContext): CoroutineScope =
    CoroutineScope(context, lifecycle)

class SomeComponent(
    componentContext: ComponentContext,
    mainContext: CoroutineContext,
    private val ioContext: CoroutineContext,
) : ComponentContext by componentContext {

    // The scope is automatically cancelled when the component is destroyed
    private val scope = coroutineScope(mainContext + SupervisorJob())

    fun foo() {
        scope.launch {
            val result =
                withContext(ioContext) {
                    "Result" // Result from background thread
                }

            println(result) // Handle the result on main thread
        }
    }
}

In the

SomeComponent

constructor you are passing

mainContext

and

ioContext

. Do these need to be defined in the

RootComponent

or just the parent component? And aside from that, how exactly are they instantiated? Thanks again

This message was deleted.

👋 i really enjoyed the droidcon app in which @Arkadii Ivanov explains how to “think in scopes” that get activated or deactivated in response to state. looks close to RIBs from UBER. anyway, there is an example on that talk about twitter screens. do you have a suggestion to split components into packages instead of all in one place and dependent from each other?

I'm trying to decide how to preserve some compose state (specifically a List's scroll state). I have screen A with the scroll state, and then screen B that uses the stack navigator to get pushed on top. And when that happens, I lose the state and

remembers

of screen A's composable. So when I pop screen B off the stack, screen A has lost where it was scrolled to in it's list. I think the strict compose answer to this is state hoisting. Something about that feels a little weird, but I suppose it can make sense?

I got a weird one here. So when using an animation with the

Children

composable, it subtly breaks certain things. I don't have a minimal case repro yet, but let me explain:

How is DI supposed to be organized in Decompose? Judging by the samples, the parent component creates the child components and passes everything via constructor, however I’m not sure about a couple of things: 1. What if we need dependencies that live longer than the component, say application-level? Using them as singletons or passing some kind of service-locator everywhere doesn’t seem too elegant. Are there any other solutions? 2. How can components be distributed to separate feature-modules without cross-feature dependencies? In samples projects either all components are located in shared/common module or a feature depends on other features?

I'm seeing the following behavior, wondering why it could be happening: 1. Start with Child A 2. Modify Child A state 3. Navigate to Child B 4. Rotate the device 5. Go back to Child A 6. The state is lost The state gets retained properly if we rotate the device on Child A. Setting

backStackCreateDepth

to 1 does fix the bug, but I'm pretty sure this shouldn't be required. 🙏

Is there a way to circumvent stuff like?

scope.launch(Dispatchers.Main.immediate) {
    navigation.replaceCurrent(...)
}

We do that do prevent runtime exceptions due to wrong coroutine context by some caller of a public API... is there a reason, why decompose enforces the main dispatcher?

hey! thanks for decompose, it’s great. quick question. is it in the plans to implement common navigation models based on generic as part of decompose? backstack and dialog exist. maybe it makes sense to have carousel/pager (as seen in the samples) and other very common ones. generic navigation allows to do pretty much any navigation one can think of but i still think there may be value in adding some as most apps use similar nav schemes.