JavaScript #3208
JavaScript #3208
Conversation
|
@Pitel: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/ |
It look like you'll have to change someting in generating code, because the |
|
Mmmm I don't think this changed recently but this is going to be a problem nonetheless... The problem can be reduced to: class MyOperation(val id: String) {
fun id(): String {
return ""
}
}My understanding is that JS classes cannot have properties with the same name as a function? If that's the case, we can decrease the occurence of name clashes with class MyOperation(val id: String) {
@JsName("operationId")
fun id(): String {
return ""
}
}To 100% remove nameclashes, it would then either be:
I think we should do 2. I'll take a look at this. |
|
@martinbonnin Do you have some ETA on the fix? |
|
@Pitel pretty hard to tell at the moment but I think you can workaround by changing the name of Operation.id in Js: /**
* An unique identifier for the operation.
*/
@JsName("operationId")
fun id(): StringThat should do until we find a more robust way to escape name clashes. |
|
@martinbonnin Thanks for the link. I didn't know where to look. Now it builds, and the tests are failing, as expected. I'll probably have to modify the existing tests, because there is no |
|
We have runWithMainLoop that is doing some specific stuff for Apple so it might make sense to add Js support there as well ( |
apollo-mockserver/src/jsMain/kotlin/com/apollographql/apollo3/mockserver/MockServer.kt
Outdated
Show resolved
Hide resolved
apollo-runtime/src/jsMain/kotlin/com/apollographql/apollo3/internal/dispatchers.kt
Outdated
Show resolved
Hide resolved
apollo-runtime/src/jsMain/kotlin/com/apollographql/apollo3/network/http/KtorHttpEngine.kt
Outdated
Show resolved
Hide resolved
apollo-runtime/src/jsMain/kotlin/com/apollographql/apollo3/network/ws/KtorWebSocketEngine.kt
Show resolved
Hide resolved
Remove forgotten println
JS doesn't have threads anyway.
There was a problem hiding this comment.
Thanks for diving into this ! That's an awesome addition, will be very welcome 🎉 😃!
One last thing before I forget. Can you remind again why we need to target the IR compiler (and therefore okio 3.0) ? That's something we might need to fine tune if we go stable before okio 3.
|
@martinbonnin Well, maybe we don't exactly need it, but JetBrains is encouraging developers to start using it. And most KMP projects and libraries I've seen and used already does. https://kotlinlang.org/docs/js-ir-compiler.html Yup, the Okio ALPHA looks a bit scary, but I would say that if the tests passes, then it's probably fine. In the begining, we've hoped that Okio 3 will be stable when Apollo JS will be finished, but is still isn't. I suppose the Okio 2 and 3 have the same API, so maybe it's possible to change the dependency just for JS builds (and "market" the JS as experimental or something)? 🤔 |
Makes sense 👍 . Thanks for the explanation!
Exactly. Experimental is fine for JS at this point. We just don't want to ship a stable JVM artifact that depends on an alpha of Okio. Follow up issue there: #3397 |
Apollo support for Kotlin/JS