Just looking for a little confirmation from the Co...
# compose-web
d
Just looking for a little confirmation from the Compose Web Devs; I'm writing an App using Compose across 3 platforms which I know is far from production approved but as a personal project I can enjoy the struggle 🙂 To be able to write a common View layer between Web / (Android + Web) I am finding the need to write a substantial shim layer with
expect/actual
to gain access to
Modifier
s that aren't available yet from common code. I guess this is partly because they don't have a Web implementation yet. Even my current Web ones are
TODO()
- I'll fill them in ad-hoc as needed. Question: Does this seem a reasonable thing to do, or am I missing a better way to handle existing API's 'commonly'?
A Horizontal
Alignment
.implementation
was missing...
Also FYI:
org.jetbrains.compose.common.ui.Alignment.Boottom*
is a typo
Two 'o's in these Bottom Alignments.
o
it feels like ideally you wouldn't need to do this (when compose-web is mature). At the same time, I can't see other viable option so far. the challenge we see with modifiers in web is that it's not always easy to "convert" the modifier into styles/attributes. @[JB] Shagen knows more about it btw, Is your project open sourced? 🙂
s
When I was writing a "common" layer to reuse, I tried to keep all the layout/styling out of it and work with logic (state/data fetch/interactions) only. That way you can abstract from differences (Android modifiers vs Desktop modifiers vs Web no modifiers) in the implementation while sharing the code, to an extent. Reimplementing Android styling system in Web with css would be quite annoying (potential project idea) 😅 If you can structure your screens into common "logic" composables and platform-specific "UI" composables, it works quite well in this context. It is also a good separation of concerns in composable world from my perspective, but maybe others will fight me on this 🙃