Check if its possible with a intercept

Not sure yet how to best achieve this, but i want the consumer be able to fully modify httpClient but it should still have the current config defaults

Possible avenues:

• Something crude that goes over the AST and generates KT DTOs
• Find a tool to convert rust DTOs to OpenAPI, then another tool to convert OpenAPI to KT DTOs
• Make ts_rs equivalent for KT

Find a tool to convert rust DTOs to OpenAPI is also needed for lemmy_openapi_spec

With K2 this is possible again.

Common

expect interface JavaSerializable

data class Post(val name: String) : JavaSerializable

JVM

actual interface JavaSerializable: java.io.Serializable

fun main() {
    val post = Post("Hello")
    println(post)
    println(post is java.io.Serializable) // True
}

I'm trying to add HidePost, and a few other related 0.19.4 actions to jerboa, but some types are missing.

Test scenarios: empty, just page, just page_cursor, both page and page_cursor, (null and value)

Test each controller

Should never send both, page_cursor takes priority and should never send pagination_guard

Parcelable has added the ability to do KMP.

see https://issuetracker.google.com/issues/315775835

Would require users, to specify the custom annotation though? Possible I would also need to add an android target :(

I'd like to add the ListPostLikes and ListCommentLikes routes in order to add the Admin View Votes functionality to jerboa, but I'm not seeing any instructions for how to do that in the README, or any scripts, like we used to with jerboa copy_generated_types.sh.

Should I do a PR to add them manually for now?

From experience, even as the author I have missed handling some explicit exceptions that were thrown. Instead I will now opt use Result so that these exceptions must be explicitly handled.

Currently I don't follow semver but I do use its notation. because with each Lemmy API change, I would have to increase my major.

Maybe I should go with a Lemmy Semver prefix notation. like 0.19.5-1.0.0. The prefix will denote the newest supported Lemmy version. And the version will denote changes to the API other than Lemmy API routes and datapoints

https://github.com/softwaremill/maven-badges

Originally I had planned to do only concrete implementations of the API every minor version, and update the existing implementation with every patch. But with release of Lemmy 0.19.4 I realize this approach is no longer feasible. Too easy to make non backwards compatible changes, DTOs are mess no longer easily visible which fields exists in which minor patch.

So instead every patch will needs it own implementation that will be an exact match for that version. Meaning it will no longer hold properties that don't exist in the current patch but in previous patch that must still be kept for compatibility.

Each patch will need its own mapper to the "universal" types. Each patch will only have the endpoints that it supports. So each patch will need to implement a wrapper for its universal endpoint.

The only drawback is that this will be significantly more work. Especially since I haven't made the universal types / API yet.

Newer versions should still fallback to an older implementation if a implementation for that version doesn't exist yet.

EndToEndTest success is defined as simply having a 2XX returned for a endpoint. We test serialization.

The only way we can reliably do this is by having a local docker instance running of a LemmyServer using TestContainers. The db should be preseeded with some data.

Then add a test for each endpoint

These tests should only be required to executed before the publishing. On demand otherwise.

I'll post logs shortly, but the error is Illegal input: Field 'id' is required for type with serial name 'it. vercruysse.lemmyapi.v0x19.datatypes.CustomEmojiKeyword', but was missing at path: $.custom_emojis[0].keywords[0]

Hi.

Thank you for this project work!

I want create an app for both ios and android platform.

Has a demo application?

LemmyNet/lemmy#4605

Will delete this from 0.19. As this is not used by the clients.