I think this question has been already answered, but I am gonna ask it again 😄 Why

val (text, setText) = +state { "Hello, World!" }

And not

var text by State("Hello, World!")

Same questions for

@Composable

actually

@Composable
fun MyComponent() {}

Instead of

fun MyComponent = composable { }

Maybe I should wait for an article about this?

The answer to the first question is ‘why not both? ‘

I did not know for the first one : O And regarding the second one, I am sure that the layer of indentation was the concern here. It seems to be a lot of work (to write the plugin for gradle, for intellij, etc), for such little benefit.

I don’t know if they would not need to make a compiler plugin

You can get

fun MyComponent() = composable { }

to work 😧

note that

var text by state { "Hello, World!" }

will be the way it will work. right now the

+

is needed. but property delegates are indeed something i’m looking forward to being used here. they didn’t work with the new kotlin compiler backend that we rely on until recently though

If you don’t have it as extension method you won’t have ‘can only be called in other composables’

regarding the 2nd question

What about the hook syntax? will it still be supported or the preferred way will be the

var text by state { "Hello, World!" }

?

both will work. your choice

awesome, thx 🙂

all of this works because the return type of

state

which is

State

implements the componentN operators and the property delegate operators

@Leland Richardson [G] Thanks for your lights! Also, I read somewhere that BLOC (mostly known in Flutter) is something that we will be able to to. Do you think that something like this would be possible? (Quick concept)

class CounterService {
    private val counter = ConflatedBroadcastChannel(0)
    
    fun openSubscription() = counter.openSubscription()

    suspend fun increment() {
        counter.send(counter.value + 1)
    }
}

//

@Composable
fun MyComponent(counterService: CounterService) {
    Button(onclick = { counterService.increment() })
    Text(counterService.openSubscription())
}

The view would be automatically updated on new values.

yeah, definitely.

I am in love... Finally found the framework that do everything I want! Can’t wait to see in action, and port it to multiplatform 😛 You’re amazing guys!

You'll probably want flows rather than channels, there are some interesting things that happen in terms of compositions that may or may not be committed, recompositions, etc. and you'll want some automatic cleanup to be at work that would be a lot easier with flows 🙂

But I thought flows were for “flux” that have an end, like reading a file. For me it’s similar to

Sequence

but async, so

AsyncSequence

. And channel, for something that doesn’t, like a event. I thinking like having an UserService, and if an user change some settings, like color, it is broadcast across the app. When a component is removed from the tree, of course, we have to think of unsubscribing. But the service will be always running.

Flows are not only for the things that have "an end" (actually it's also true for sequences). Essentially you probably shouldn't expose any channel API, channel may be used as implementation detail, but Flow API is more safe and powerful for consumer

broadcast across the app

Right, and to subscribe on this broadcast you consume it using Flow. Under the hood it will be a channel for now, or upcoming DataFlow or Flow.share()

So we will be able to use flows for events?

With DataFlow it would look like in this doc on your link, but even now, without DataFlow, you can use Flow API, just replace counter.openSubscription() with counter.asFlow()