This is VERY stupid... the following pattern seems occurring quite frequently when writing compose c...

# compose

[ste]

This is VERY stupid... the following pattern seems occurring quite frequently when writing compose code:

@Composable
fun Element(state: ElementState, content: @Composable ElementScope.() -> Unit) { ... }

class ElementState {}

@Composable
fun rememberElementState(): ElementState { ... }

class ElementScope {}

I was wondering why it is preferred against the version in the thread?
The guidelines do not mention it.

[ste]

The idea is to have a common namespace (I used the class keywords randomly here)

class Element {

   companion object {
       @Composable
       fun Display(state: State, content: @Composable Scope.() -> Unit) { ... }
   }

    class State {
        companion object {
            @Composable
            fun remember(): State { ... }
        }
    }

    class Scope {}

}

[Kirill Grouchnikov]

Let's not start a discussion with labeling something as stupid or very stupid - unless you want to push people away.

[Timo Drick]

For namespaces you could just use packages or am i wrong?

[Adam Powell]

decoupling these things at the top level is deliberate and invites outside contribution to an API surface. Someone else can add alternative/additional API surface that accepts or returns ElementState from another module, effectively creating peer API that looks and feels the same. They cannot add more nested class elements to a class outside of their module/library.

[ste]

"This is stupid"... I meant what I was going to say might have been stupid, not that the actual code pattern is stupid 😅 Sorry guys!