https://kotlinlang.org logo
Join Slack
Powered by
I am struggling to get my compose web to run in a ...
# compose-web
d
I am struggling to get my compose web to run in a multiproject multiplatform layout: root project is defining all plugins but all with apply = false Now project compiles fine, but 
gradle jsBrowserRun
shows an empty Browser page, I guess because build/processedResources ends up in the subprojects build folder, but build/js ends up in the roots build folder ... how do I get this to work from the js being soley in the subproject?
b
do you have index.html in your js resources referencing your 
[module-name].js
file?
d
I only copied my working js project into the subproject folder of my multiproject layout, its resources index.html is unchanged:
Copy code
<body>
<div id="root"></div>
<script src="minimal_compose-web.js"></script>
</body>
being in the suprojects src/jsMain/resources folder I just adjusted the src attribute to the name of the js suprojects name+".js"
Copy code
$ cp web/src/jsMain/resources/index.html ./web/build/compileSync/main/productionExecutable/kotlin/
$ chrome ./web/build/compileSync/main/productionExecutable/kotlin/index.html
it works if I copy over the index.html to the generated productionExecutable. But neither works on 
./gradlew jsBrowserRun
nor on 
./gradlew web:jsBrowserRun
b
You shouldn't need to copy for jsBrowserRun
Hold on, your index.html does get served, right? Otherwise you'd see 404 page
d
that's my understanding too. But it doesn't find the 
minimal_compose-web.js
on jsBrowserrun
b
what's your gradle module name?
d
subproject name is web,
Copy code
include(
    ":common",
//    ":android",
    ":desktop",
    ":web"
)
b
then your js file for jsBrowserRun will be 
web.js
d
aaaaah, right ... that did it. thanx
👍 1
so the local jsBrowserRun index.html has to be a bit different, than what I'd deploy to a production site? as there its name should be 
minimal_compose-web.js
instead of 
web.js
??
b
Not sure. Run gradle build and see what gets packaged in build/distribution
I think it will still be web.js
d
yep, you're right, is still web.js thanx for your blazing fast support. (I am sure even a bot would have struggled to beat your MTTR (mean time to repair) in this case! 🙂
b
Hah, faced this issue myself plenty of times so I know the pain all too well 😄
d
proves that nowadays a Brain is yet still stronger than AI 🙂
btw, is there a doc/site saying what @Composable stuff does work with kotlin js compse and what of it only works with android/desktop/native ?
b
Don't think so, but basically only core and runtime compose artefacts are available for js. No material stuff or foundation
d
(think for "real" write once run on any platform (including web) for compose we'll have to wait for WASM anyways ... at least my feel of it)
b
They're working on canvas-based material support right now
d
very keen on 1.6.20 therefore ...
b
There's also my github.com/mpetuska/kmdc for accessibility conscious projects (very experimental still)
d
they said it'll have webassembly target (at least for multiplatform, not sure about compose)
b
I would not expect WASM being anywhere close to production-viable (not even ready/stable) until late 2022
d
atm just trying to convince my company to give compose a shot (being still angular/react) so for me it would be enough if the current compose WASM support would just make them "wow" 🙂
b
Well current compose (without wasm) should still wow them
Compare it with vanilla react
All it's missing right now is some components lib. But it handles plain DOM management exceptionally well
And dev experience is amazing (other than long reload times after change, but that's kotlin issue)
d
well get people away from js/ts is some religeous subject I think. otherwise js/ts would have extinguished long time ago
7 Views
Open in Slack
PreviousNext
Powered by