This is VERY stupid... the following pattern seems...
# compose
s
This is VERY stupid... the following pattern seems occurring quite frequently when writing compose code:
Copy 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.
🚫 1
The idea is to have a common namespace (I used the
class
keywords randomly here)
Copy code
class Element {

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

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

    class Scope {}

}
k
Let's not start a discussion with labeling something as stupid or very stupid - unless you want to push people away.
💯 4
☝️ 16
☝🏻 1
t
For namespaces you could just use packages or am i wrong?
a
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.
s
"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!
❤️ 1