Hopefully soon-ish, yes. It is very much somethin...

# compose

[jim]

Hopefully soon-ish, yes. It is very much something we want to enable. We've always said that your composable functions should be pure functional transforms from input data into UI, should be side-effect free, and should make no assumptions about which thread they or their children run on. These rules, while not enforced as strictly as I would have liked, have always existed for a few reasons. Firstly, they make your code more understandable+maintainable and generally just better. And secondly they exist because of the way memoization and skipping already work. But most importantly, they are necessary for your composables to not break when we roll out multithreaded composition.

Even internally, we probably have some widgets that we wrote incorrectly which will break if we turn on multithreading, so it'll probably be possible to enable/disable with a flag to start. But it is very much something I'd like to see sooner rather than later. The faster we can get it rolled out, the easier it will be to help migrate the existing users. It is very much a work in progress, and will take some time to finish, test, and roll out - but we'll let you all know as things continue to progress.