<@UFT11FKSP> Following up on my RestClient/deseria...

# kvision

[Christer Palm]

@Robert Jaros Following up on my RestClient/deserialization challenges...
Indeed, moving from LegacyRestClient to RestClient did not improve deserialization performance at all 😞
Using requestDynamic() improves performance greatly, but some objects need to be Kotlin objects down the road.

Fortunately, the bulk of the REST response works just as well with plain JS objects.
For elegance, I'm wondering if it's possible to make a hybrid approach? Something like:

@Serializable
data class MyResponseType(
    val hugeListThatDoesntNeedDeserialization : dynamic,
    val deserializeThis : MyType,
    val deserializeThisToo : Array<String>,
)

...
    val responsePromise : Promise<RestResponse<MyResponseType>> = restClient.receive<MyResponseType, Nothing>(url) {
        deserializer = MyResponseType.serializer()
    }

I.e. tell the Kotlin deserializer to leave some elements alone? Does receive() even work off JS objects, or does it work with a character stream?
I know that's more of a deserialization question, but maybe you know?

[Robert Jaros]

I don't think it's possible.

[Christer Palm]

OK, I ended up using RestClient.requestDynamic() and then converting the necessary elements to Kotlin objects using Json.decodeFromDynamic().
That'll do it. Thanks for your help!

Another unrelated-but-yet-related question;
I get a progress bar at the top of the page that I can't figure out where it's coming from. Can I control that? Or is there an alternative "progress indicator" component that I can use to provide a visual cue that the application is processing in the background?

[Robert Jaros]

Do you use kvision-pace module?

[Christer Palm]

Sorry for the late response.
I've been doing a bit more digging, and indeed it's using kvision-pace module.

My problem seems to have appeared after updating from KVision 7.0.0 to 8.1.0.
Before, it kept spinning until all background processing was complete, but now it goes away prematurely.
With background processing meaning a bunch of stuff kicked off with GlobalScope.launch.

The only interaction with the API is Pace.init() and Pace.start() so my code obviously runs with the default options/automation.

Is there anything obvious I can tweak to make it keep spinning until background processing is done?

[Robert Jaros]

By default the pace library shows the progress bar by monitoring ajax requests and guessing when it should start and stop. You can read about this here: https://codebyzach.github.io/pace/docs/ (Tracking chapter).

[Robert Jaros]

I usually don't use pace in automatic mode. Instead I use manual mode and use show and hide methods to manually control the progress bar visibility.

[Robert Jaros]

I use function like this as a wrapper around async tasks:

var paceCounter = 0

suspend fun <T> withProgress(block: suspend () -> T): T {
    Pace.show()
    paceCounter++
    return try {
        block()
    } finally {
        paceCounter--
        if (paceCounter <= 0) Pace.hide()
    }
}

[Robert Jaros]

But there was no change in the pace module between KVision 7 and 8.

[Robert Jaros]

You shouldn't see any difference so it is a bit strange.

[Christer Palm]

Hm, it might also of course be related with my migration from LegacyRestClient to RestClient(?)
I did study the Pace docs, but it didn't really provide me with any clues as to why the automatic processing stopped working.

Should be simple enough to change it to explicit control as per your example, so I think I'll try that next, thanks!

So if I understand it correctly, show() will make it appear until I do hide(), in contrast to start() which will make it stop automatically?

[Robert Jaros]

I'm sure it is related. The legacy rest client works with jquery and typical ajax (XMLHTTP).

[Robert Jaros]

New rest client uses fetch api and it's probably not supported by pace.

[Robert Jaros]

There is even an issue https://github.com/CodeByZach/pace/issues/333

[Christer Palm]

Ah, I see that explains everything.
OK, but controlling it explicitly makes sense anyway, so I think that is the best solution.

[Christer Palm]

That will also make it cover some internal processing that happens after the rest requests have completed.