One Off the Slack: Reworking Recomposer

Andylamax asked:

Why do need to call setContent(Recomposer.current()) {} in fragments? and if we must pass a Recomposer as a parameter, in which scenario would I need to pass another Recomposer?

Google’s Adam Powell answered with information about a potential upcoming change. They might get rid of the setContent() extension function on ViewGroup:

We’re probably going to remove the ViewGroup.setContent extension altogether in favor of some sort of public AbstractComposeView that accepts a composable function as a required constructor parameter. Since the current extension has to create one anyway, and today it’s just an added layer of view hierarchy.

To Andylamax’s concern, Adam points out that Recomposer.current() is “thread-specific”. If you look at the dev13 implementation, it relies on a ThreadLocal and has guard logic to require you to be on the main application thread when trying to retrieve it. And that is a bit icky, or as Adam put it:

…binding to the current thread by default has been a source of issues in other Android APIs over the years. Being explicit is better here.

---

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!