I wonder, is it possible to do something like this...

# compose

[Fudge]

I wonder, is it possible to do something like this?

@Composable suspend fun askQuestion() : Answer {
   return suspendCoroutine { continuation -> 
      QuestionComponent(onAnswer = {answer -> continuation.resume(answer)})
   }
}

The problem is that if I do something like this

setContent {
    runBlocking { askQuestion() }
}

It won't compile because "@Composable invocations can only happen from the context of a @Composable function"

[Adam Powell]

Yes, but the shape ends up being something a little different. Composable functions are declarative, they have to be able to answer questions about the state of the UI immediately and synchronously.

[Adam Powell]

Your hoisted state objects can manage their own state based on suspension, however

[Fudge]

Do you have an example?

[Adam Powell]

yep, was just digging it out of my gists from a couple months ago 🙂

[Adam Powell]

https://gist.github.com/adamp/47f2762d70bc33a5e2c75a31413ec202

[Adam Powell]

specifically, take a look at the SnackMenu class - that's the hoisted state object bridging suspending request-response API with compose-aware state

[Adam Powell]

the rest outside of that is basically placeholder

[Adam Powell]

substitute the snackbar data with your question data from your code snippet and you can see how this sort of thing can fit together

[Fudge]

I never understand creating an interface for one implementation

[Fudge]

thanks, this is roughly the same thing

[Adam Powell]

in this case because kotlin doesn't let you declare the constructor of a concrete class as being private to a containing class, or file-private

[Adam Powell]

outside of a library setting this would matter a lot less

[Fudge]

wouldn't private constructor do exactly that?

[Fudge]

i.e. class Snack private constructor(...)

[Adam Powell]

no, the containing class can't construct it if the nested class's constructor is private

[Adam Powell]

only the Snack class or its companion object could call it

[Adam Powell]

so then that just moves the visibility games to the companion object and the same problem exists

[Adam Powell]

the public interface/private class thing is a bit repetitive but ends up clearer than those alternatives in most cases

[Leland Richardson [G]]

FWIW, in dev16 the code you posted at the top of the thread will fail to compile with a different error message:

“Suspend functions cannot be made Composable”

[Leland Richardson [G]]

right now composable suspend functions are difficult to assign a meaning to, and we don’t compile them in any useful way right now, so they are just disabled completely. We have some ideas on what it might mean in the future, but by preventing them now we unlock the ability to enable them in the future in a non-breaking way once we have a better idea of how a suspend composable function should behave.