-
Notifications
You must be signed in to change notification settings - Fork 510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support wasmJs target #4965
base: master
Are you sure you want to change the base?
Support wasmJs target #4965
Conversation
Is the conversion to |
Sure, I will revert this change |
2c9fe7e
to
5c2d9a3
Compare
@dellisd Hi!
|
fadbd3e
to
9c998de
Compare
@dellisd Hi!
|
0f55176
to
8d53f00
Compare
I'm not sure why, but instrumentation tests are failing on CI. |
Turbine 1.1.0 with wasmJs support is out |
Replaced Turbine snapshot with |
f5f4c46
to
8253cfb
Compare
Currently trying to fix tests 🙂 |
49e197c
to
672ff65
Compare
5ba62bc
to
7e91ea4
Compare
8838b26
to
f3fbc73
Compare
@dellisd Hi! |
e6bc4cb
to
73d0a59
Compare
73d0a59
to
20267be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good, but there are some changes to the public API that I think we should make and I'm a little unclear on why certain parts of the Wasm implementation can't be shared with the Js implementation.
drivers/driver-test/build.gradle
Outdated
@@ -23,9 +26,11 @@ kotlin { | |||
watchosX64() | |||
watchosArm32() | |||
watchosArm64() | |||
watchosDeviceArm64() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because these aren't directly related to adding Wasm support, I think these would be better split out into their own PR to introduce support for these targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
I don't really remember why I've added them. AFAIK, because of some tests failing, but I can't reproduce it now.
testTask { | ||
useKarma { | ||
useChromeHeadless() | ||
} | ||
} | ||
} | ||
} | ||
applyDefaultHierarchyTemplate { | ||
it.common { | ||
it.group("jsCommon") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any need for this to be jsCommon
instead of leaving it as the default common
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you are right, it's unnecessary. My bad, I'll remove this group.
|
||
import app.cash.sqldelight.db.SqlDriver | ||
|
||
expect fun createWebWorkerDriver(): SqlDriver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The web worker driver is designed to support more than just one worker implementation, so this function should be able to accept a Worker
parameter to allow a consumer to define which worker should be loaded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is still possible to create WebWorkerDriver with custom Worker
.
I think we could just rename this method to createDefaultWebWorkerDriver()
instead.
* @property worker The Worker running a SQL implementation that this driver communicates with. | ||
* @see [WebWorkerDriver.fromScriptUrl] | ||
*/ | ||
class WebWorkerDriver(private val worker: Worker) : SqlDriver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which elements of this class (and its jsMain
counterpart) can't be lifted into the commonMain
implementation? Ideally I think we would have one common implementation of the worker driver, and then expect
/actual
the web API bits (i.e. Worker
) as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, most of it 🙁
I have tried to make it as common as possible, but found out that currently there's no way to do it properly.
Most of JS APIs are not common between js
and wasmJs
.
Current wasmJs
interop is quite limited.
It does not support: Array, dynamic
in external types. Also, it does not allow arbitrary types which are not extending JsAny
to be passed to external functions.
This means that we cannot share WorkerRequest
, WorkerResult
, WorkerResponse
.
Also, we would need to expect/actual quite big portion of Worker
API with custom wrappers all over the place.
I will try some more ways to commonise as much as possible and show you in a couple of days, maybe we will find a better solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need Kotlin 2.0 for this change too? I bumped it in this PR #5217, but I will break my PR into smaller ones. |
Not really. |
Any updates on this? |
…her than 23 is required)
…available for androidNative
…eDefaultWebWorkerDriver()`. remove unnecessary `jsCommon` group from web-worker-driver.
…datetime to 0.6.0. remove expect/actual classes warning
824c9fc
to
bfe3d03
Compare
Any update on the same. |
Any update on this please? |
I am also interested in wasm support, it would be very nice to have it ready. |
can we get an alpha (early access) version with this change to try it out ? 🙏 |
I was developing a multiplatform library and needed to implement a database. After adding SQLDelight, I realized that the plugin causes errors in the wasmjs module, essentially forcing me to remove this module because there's no way to ignore the error and use SQLDelight on other platforms while handling storage differently in wasm. Currently, libraries like Koin, Ktor, ViewModel, and Lifecycle support wasm, and the lack of SQLDelight support is noticeable. |
What's impossible for now:
WebWorkerDriver
can't be done without support for Kotlin arrays interop withwasmJs
: https://youtrack.jetbrains.com/issue/KT-57125/Add-interop-with-JavaScript-arrays-to-Kotlin-WasmChanges:
wasmJs
target inMultiplatformConventions
and:driver-test
.jsCommon
source set containing common code forjs
andwasmJs
targets.jsNativeCommon
source set to:runtime
module containing common code fornative
,js
, andwasmJs
targets.watchosDeviceArm64
andlinuxArm64
because of failing tests.WebWorkerDriver
forwasmJs
target. Fix all tests to be passing.