Kotlin / kotlin-fullstack-sample

Kotlin Full-stack Application Example

Home Page:https://kotlinlang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Duplication of package org.jetbrains.demo.thinkter.model

seanf opened this issue · comments

The classes in the multi-platform package org.jetbrains.demo.thinkter.model are duplicated between backend and frontend (except PollResponse which is missing from frontend).

I suspect a full solution for this requires https://youtrack.jetbrains.com/issue/KT-6359 but see also https://github.com/jstuyts/kotlin-multiplatform-recipes

If you look at the git history, there actually was multi-platform support in here before the repo was publicly released. I suspect it was removed so that this can be a clean reference example without depending on experimental/unsupported features.

Fair enough. I think it's good to capture this architectural limitation explicitly, until a better solution for sharing code between client and server is in place.

I was hoping I could use the techniques here to convert a Java+GWT project to Kotlin, but it's not practical to duplicate that much shared code. I'll have to see what happens with https://youtrack.jetbrains.com/issue/KT-6359

This feature is crucial, at work we have around 350 model classes...
Once this is solved:
And any opinions on how to reuse JSR303 annotations on the client side?
I don't want to rewrite all the validation logic...

@biberesser
I hadn't considered that aspect. I wonder if https://github.com/ManfredTremmel/gwt-bean-validators could be converted to Kotlin - although I suspect it may be a lot of work to make it independent of GWT, eg ManfredTremmel/gwt-bean-validators#3.

This feature is crucial, at work we have around 350 model classes...

Agreed. The big point of Kotlin seems to be "stronger typing", and carrying types between FE and BE is crucial.

And any opinions on how to reuse JSR303 annotations on the client side?
I don't want to rewrite all the validation logic...

JSR303 annotations; is there not a way to deal with this in a more "in code" way than using annos.
I feels Kotlin might have a terse enough syntax to allow for a sweet API in this domain.