I have a strange issue with wasmJs and compose runtime. My project uses the same, common code to implement compose runtime applier to manage DOM nodes for both JS and WasmJS targets. And I have just noticed that my compose engine works differently in JS and WasmJS targets with exactly the same code. The difference is that wasmJs app triggers many more node removal calls when using some advanced composables (I'm porting lazy-layouts from OpenSavvy). The final recomposition effect is the same, but there are noticeable scrolling side effects. I was convinced compose runtime manages the tree with a strict algorithm. How it is possible that the same code triggers different composition effects? Could it be a bug in Kotlin/Wasm or Compose Wasm runtime implementation? Is there any way to debug this?
Slack Conversation