You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a design system that supports web, compose, and swiftui. I am the team's only android engineer. We get a lot of feature requests and asks for some of the multiplatform frameworks. I was interested in experimenting and seeing if I could generate a react native/flutter/kmp library from our existing compose library.
We are also in the process of spinning down our views/xml library in favor of compose, but it would be cool if maybe mitosis could help us keep it around. The existing interop api would require us to maintain a whole mapping of compose -> views and that's about the same effort as just keeping views around. A less painful (maybe AI powered) way of keeping views around would be appreciated. We have some crusty codebases here that are maintained by engineers with little interest in migration to compose.
@Composable
fun greet() {
val state by remember { mutableStateOf("hey steve") }
Column {
TextField(value = state, onValueChange = { state = it }, label = "Your Name")
Text("Hello, ${state.value}")
}
}
As far as inputs I would like the targets prop of MitosisConfig to have at least Compose if not ComposeMultiplatform, Flutter, AndroidViews.
Additional Information
I'd be sorta interested in doing some of this implementation if it would save me some time helping my design system's users use multiplatform frameworks more easily.
The text was updated successfully, but these errors were encountered:
I think a generator would be awesome for compose and/or swiftui, but generting another technology is pretty different than generating for another web-framework.
There wouldn't be a problem for state & props I guess. The problems would be the elements and styling. In your example, your would convert a div to a Column which is fine for the default display:block but in case you have a stying via .css or as useStyle you might get a complete different compose component.
Additionally <input placeholder="Your name"> wouldn't be TextField(label = "Your Name"). In web you need to write<label><input />Your name</label> or <label for="xx">Your name</label><input id="xx"/>. There are some cominations and you need to resolve them all.
I think it is very hard to accomplish a good generation of compose or swiftui components with mitosis. :(
you can generate a react native normally using mitosis, it supports react native, and as far as i know it generates Swift, Which means you can create a generator for android normally actually it will be great if mitosis supports android too.
I am interested in helping provide a feature!
Yes
Which generators are impacted?
What problem does this feature solve?
Hey from Amazon's Meridian team,
We have a design system that supports web, compose, and swiftui. I am the team's only android engineer. We get a lot of feature requests and asks for some of the multiplatform frameworks. I was interested in experimenting and seeing if I could generate a react native/flutter/kmp library from our existing compose library.
We are also in the process of spinning down our views/xml library in favor of compose, but it would be cool if maybe mitosis could help us keep it around. The existing interop api would require us to maintain a whole mapping of compose -> views and that's about the same effort as just keeping views around. A less painful (maybe AI powered) way of keeping views around would be appreciated. We have some crusty codebases here that are maintained by engineers with little interest in migration to compose.
What does the proposed API look like?
A react example like so:
could become
As far as inputs I would like the
targets
prop ofMitosisConfig
to have at leastCompose
if notComposeMultiplatform
,Flutter
,AndroidViews
.Additional Information
I'd be sorta interested in doing some of this implementation if it would save me some time helping my design system's users use multiplatform frameworks more easily.
The text was updated successfully, but these errors were encountered: