is it possible to be used with Flutter?

[codeitlikemiley]

I know flutter have a Flutter Rust Bridge,

But i wanna know if it is possible to use Flutter instead of Swift UI or Jetpack Compose ....

[charypar]

It should be possible, but there are a few hurdles we haven't overcome, mostly because the Flutter use-case seems somewhat weak - if you're going to build UI in Flutter, you could adopt the architecture and build in Dart. That said, I'm sure there are hybrid approaches where it would be valuable.

We're interested in supporting Flutter, but to be fully transparent - we don't have a gread deal of experience with Flutter or much need for it, so we'd love to find a champion for that integration to help get it working.

Flutter integration has first been discussed in #78, can we continue the discussion in that other issue, please?

[dancixx]

@charypar same question in case of react-native, is it possible to use it? I went through the documentation and examples but I am not sure whether is it possible to use or not.

[charypar]

@dancixx In theory, yes. 🙂

In practice, getting it through the build tooling might be a bit challenging. I see two approaches that should work:

1. attempt to get a wasm build working in RN - quick google found https://github.com/cawfree/react-native-webassembly, which may be an option
2. link Crux in like you would in a native app, and use the RN bridging to surface the Crux API to your TypeScript code. You could still use the generated TypeScript types, you could even keep the native bridge really minimal and deserialize the data in TypeScript.

We don't have examples of this setup, because it seems like a somewhat redundant stack. The primary target for Crux are the native UI frameworks in order to get a native, idiomatic user experience. If you're building in React Native already, you might as well build the whole app in TypeScript, there isn't a great deal to gain from having Crux involved (other than the magic of Rust 🦀), and it should be entirely possible to replicate the Elm-like architecture with something Redux-like and 90% of the testability benefits.

Now with that said, I can certainly imagine a scenario in which for example you'd want to use Crux to support a platform not supported by React Native yet (let's say a CLI, or reusing the code ona server, for the lack of a better example), or you might want a gradual migration path from React Native to Crux with Swift UI and Jetpack Compose, in which case one of the two approaches above should work - ultimately the Crux core is quite a straightforward library, from the perspective of the shell.

Curious about your use case, would you mind sharing some more context?

[dancixx]

@charypar my main motivation is using rust everywhere if its possible. I am really big fan of rust and on other hand I love to use react-native to make mobile apps. It is not real native but using native components what is much better like flutter canvas solution and more time efficient like native solutions, and if u are take care about performance it almost the same like native, and futhermore the new arch is really promising in case of performance. There are some examples how is it possible to use rust code in react-native but it requires some c binding so it doesnt worth it that way. Btw this project is awesome and there growing and promising rust based cross platform solutions like Xilem, Ribir, Tauri etc. which can give us alternatives.

[charypar]

Ah, well that makes perfect sense to me, Rust is indeed amazing 🙂 If you do try getting Crux to work with RN and hit any barriers, feel free to open issues, link to some half-working code, or join us on Zulip and we'll try and help where we can.

[seanstrom]

I'm just discovering Crux and it seems really promising for defining a core for React-Native apps. Currently I'm using React-Native for mobile and desktop apps, but I was thinking that Crux could be a better investment since the code would seem more re-usable. "Re-usable" in the sense that I can start writing the core and use React-Native for creating the iOS and Android apps immediately, and if I ever need to more control it would be possible to re-write any of the shells with a more native shell.

I'm also interested in how the fairly new JSI bridge could affect the Crux architecture, since it could help avoid some async bridge communication between React-Native and Crux. Any thoughts here?

cc @charypar @dancixx

[charypar]

React Native is another thing we haven't really tried with Crux yet, but would be super intereested in how it might work. I'm not up to speed on the JSI bridge, so unfortunately can't really comment.

Maybe @StuartHarris or @tkeburia might know more?

[seanstrom]

My simple take on JSI is that we can support interop with JS objects directly, so we can skip an extra encoding/decoding step. Additionally, it allows for synchronous interop with between the layers, which could be useful for calling a native function for managing a state machine.

The main downsides (as I see them) is that we have to define JSI bindings using C++, but there is a JSI rust crate (experimental) that essentially wraps portions of the C++ library.

This got me thinking of a potential strategy which involves using a combination of the JSI rust package, uniffi, and some custom serde encoders/decoders. For example, we would define the JSI bindings in Rust with jsi-rs, and then we would use uniffi to generate the Swift and Kotlin bindings for initialising the Rust layer to register the JSI stuff. So in the end the Rust layer would handle encoding and decoding the JSI values and registering the JSI functions for the JS runtime.

That all said, this is all still napkin schematics, so I have some tinkering to do 😄
But I thought I would share my thought process here, if anyone is interested please lmk 🙏

[charypar]

So long as we can exchange byte buffers over JSI with a C-like library, it should be possible to reuse a lot of the existing infrastructure. I don't think it will be possible to avoid ser/de, but the Crux FFI has very different usage characteristics from the classic RN bridge, so that work is not as much of a bottleneck. I'd look at creating that sort of shim first.

Definitely do share how you get on! 🙏🏻