to clarify, of course I have an implementation elsewhere, like: ```class CustomImageLoader : ImageLo...

# compose

[Chris Fillmore]

to clarify, of course I have an implementation elsewhere, like:

class CustomImageLoader : ImageLoader {
  @Composable
  override fun Image(url: String) {
    // Load and draw the image
  }
}

[Sean McQuillan [G]]

This is a class based composable, which we used to ship.

[Sean McQuillan [G]]

It was removed because the list of rules about what you can update and when are decidedly not class-like. You can make it work however, if you remember that the implicit this pointer is a parameter to Image

[Sean McQuillan [G]]

If you do go down this route, to make it easy, I'd suggest making all members State<T>

The mapping to make it work correctly:
ctor args -> composable parameters
class members -> hoisted state to a composable
local remember -> composable state

Note that class members in this structure are not equivalent to local state, as they may be shared with multiple invocations (instances) of Image

[Chris Fillmore]

Thanks for the info. My intention is not to use class member state in the Composable, but just to hide implementation detail / external dependencies

[Sean McQuillan [G]]

It's fine to use it for namespacing like this, though also consider using an object so people are less likely to add state to the object.

[Chris Fillmore]

good idea! I think I could do that