Is there a more idiomatic way to have a wrapper around an HttpClient that sets up some default featu...

# ktor

[Paul Griffith]

Is there a more idiomatic way to have a wrapper around an HttpClient that sets up some default features, but also allows some use-site customization? More in a thread, but basically I want to be able to create an XClient which might be backed by a CIOEngine...but also be able to use the same class but with a MockEngine, which requires being able to add handlers

[Paul Griffith]

I've got an abstract class like this

Untitled

[Paul Griffith]

Then impl classes look like this (adding additional features)

Untitled

[Paul Griffith]

Which then allows customization at the use site like this:

Untitled

[Paul Griffith]

But the stuff at the abstract class feels very weird and unergonomic

[Paul Griffith]

Guess I answered my own question, making the second parameter on the abstract class

engineCustomization: EngineType.() -> Unit = {},

which then makes the client initialization

protected val client: HttpClient by lazy {    HttpClient(clientSupplier.create(engineCustomization), clientConfiguration)
}

makes things a lot nicer to look at

[Paul Griffith]

Just kidding, that can even be reduced further, because HttpClientEngineFactory has a create extension function, so you don't need to provide a configuration lambda at all