A modern programming language that makes developers happier.

kotlinlang

I feel really bad because I need to run quite few `Canvas` calculations and so i need `size`. To clean things up i created a viewModel and passed a `viewModel.setValueAsWasUglyWIthTheAdapters(size:Float)`  and in the viewModel I have a property that get the value and use it everywhere( Is not a flow because the size is not reactive. But I feel really bad, this is bad architecture, even because I do not want to pass the ViewModel in the composable, that should be stateless 100%. `What is the `UncleBobbest` way to proceed when you need to perform heavy weight calculations from variable that come only in the view? Maybe untestable extension functions instead of the VM, or am I missing a design pattern dedicated?

Depends what you do. Does calculation require any DI or special logic only accessible from VM?
If not I would probably using state holder for the composable, but as I dont know context hard to know if fits. By using state holder it can also be observed from other composables. I try to avoid them but could maybe serve its purpose.
Otherwise would use state hoisting with callback/lambda delegate size back to VM, and update ui state in it and propagate ui state using UDF pattern.
Thats what I can think of right now.

thanks Joel, i do not need any manual or library DI, the view model idea comes only from the old purpose of putting business logic away from the view, and so i guess can consider a viewmodel as a state holder, to do the hoisting, looks really `flutterish` to make a kind of state machine, I am doing a proof of concept for a library i am writing, is the fact that `I would move to the the vm ONLY events` and `NOT` a view internal, otherwise would look as a `MVC` old architecture

Anyway all the new  guide from the official  site looks to me is boiling the ocean, because is the old clean architecture after all, UDF is nothing new even not with MVVM, hope anyway is going to be universally adopted, and nice Alphabet is giving this cool guidelines

Last time I had to do this, I added a onSizeChanged: (Size) -&gt; Unit parameter and a currentSize: Size parameter, leaving it up to the caller of the Composable to define how to change the size (and making it more testable)

<@U3XR6UWTZ> with state holder I refer to this:
<https://developer.android.com/topic/architecture/ui-layer/stateholders#state-holders|https://developer.android.com/topic/architecture/ui-layer/stateholders#state-holders>
Like example rememberLazyListstate().
If prefer state hoisting can still using your viewmodel, just never send it to composable. I agree Google done a lot of good architecture guidelines in Compose lately. 
I usually like to ignore patterns used outside of composables and see as pure ui having ui state only and nothing else. They should imo not be aware of viewmodel, domain logic and if possible not even platform logic like Android. Once doing that it will become a lot cleaner in Compose code and easier maintain.