https://kotlinlang.org logo
Join Slack
Powered by
It seems Compose for Web targets a canvas rather t...
# compose-web
m
It seems Compose for Web targets a canvas rather than the traditional DOM; How does this affect accessibility tools (such as screen readers, but also things like text selection, copying links, etc)?
b
There's also compose html that targets traditional dom
d
Yeah, this channel confusingly means both right now, since Compose HTML used to be Compose Web (some of us would probably prefer if they forked off a compose-html channel) but yeah, there are some of us here doing Compose HTML work, targeting the DOM.
➕ 3
m
The main reason I asked is because many libraries using Compose (such as #decompose) mostly only support the WASM targets, and accessibility is a big concern for migrating
b
What? I could swear decompose supported compose-web way before wasm was a thing
@Arkadii Ivanov please correct me if that's not the case
a
Decompose has been supporting Compose for DOM for quite some time already. There are samples here: https://github.com/arkivanov/Decompose/tree/master/sample/app-js
Ironically, it doesn't support WASM yet 😀
m
Huh, just yesterday I was told the extensions-compose-jetbrains module didn't support the DOM and I had to make a lot of its components by hand
b
Here's the key reason why compose-web (wasm) came to be - compose-html did not facilitate reusing CfD and Jetpack UI components on the web due to significant UI pipeline differences (not impossible, but very hard). There were some early attempts made to bridge this gap for compose-html, but those were quickly abandoned once the team realised the volume of work required to achieve and maintain this. So from that point onwards, compose-html allowed sharing your business logic and compose state, utilities and other non-ui stuff, but sharing ui was out of reach. This new compose-wasm (unofficial name) drops the dom which was the main blocker for ui sharing and instead draws on canvas via skiko (same rendering engine used by CfD and jetpack), which unlocks shareable UI, but loses web accessibility features. So now you have a decision to make - choose compose-html if you need accessibility over ui sharing or compose-wasm if you would rather have shared ui.
➕ 2
Hope that clears some things out for you
For now, when you look at readmes in gh repos and see compose-web mentioned there, most of the time it is still referring to compose-html given that wasm (and in turn current compose-web) is still experimental
a
Regarding Decompose, there are two modules: 
decompose
and 
extensions-compose-jetbrains
. The former provides the navigation itself (UI agnostic) and it does support Compose for DOM. The latter doesn't support Compose for DOM exactly due to the reasons explained by @Big Chungus. All you need from that module is just the Children function without screen animations, you can just copy that code (~70 LOCs).
Currently Decompose has one important limitation on Web: nested navigation can't be reflected in the browser history, only one level can be in the history. So if you need only the Web target, maybe there are better libraries out there.
b
For web I've been using routing-compose which is basically react router reimplemented for compose. Pretty simple, easy to setup and works very well for me. It does support jetpack and desktop as well, but I've never tried it there so can't comment on the experience
s
surely you could get things like accessibility and reader support with future browsers, maybe via wasi (i'm not sure) it doesn't seem insurmountable but i have no experience in that area.
b
Everything is possible, it's just a question of whether people are ready to put in the effort. We're talking short term here and accessibility on canvas is simply not on the horizon.
a
Btw, if I understand it correctly, React Navigation also doesn't support browser history with nested navigation without reloading parent components. There is a feature request: https://react-navigation.canny.io/feature-requests/p/navigating-within-one-route-in-web-should-add-that-navigation-to-browser-history. But I might be getting it wrong.
c
@Big Chungus Do you mean https://github.com/zsoltk/compose-router? It's marked as deprecated
a
h
Guess, I should rename the title to compose html
b
Or just add wasm support 😀
a
Another compose routing solution which should work on both wasm, dom and any other compose target would be captain
27 Views
Open in Slack
PreviousNext
Powered by