UniFFI support #43
UniFFI support #43
Conversation
|
The documentation for UniFFI has changed dramatically over the last 2 months and is worth revisiting. When Elle originally tried swift-bridge, UniFFI was without an async section in the guide book and the recommendation was to define types using a UDL file, but there is now procedural macro support and it is all kinds of awesomeness. Hopefully UniFFI is able to replace core-jetpack because JNI is truly awful to work with and lacks async support. One thing to consider with UniFFI is that types wrapped in Arc by the constructor will need interior mutability. It should be possible to use qcell to provide mutability and in doing so it's conceivable Morph could also be used in a way that doesn't necessitate collecting patches by applying iteratively as to avoid heap allocations. The key here is that by separating the borrow-owner any Cursor that referenced a document could be held beyond the lifetime of the call to get the next patch so that the document editor can take a mutable borrow when otherwise the Cursor borrow would prevent this. |
simlay
force-pushed
the
simlay/34-uniffi-for-ffi
branch
from
b11d850 to
740bd66
Compare
simlay
force-pushed
the
simlay/34-uniffi-for-ffi
branch
from
740bd66 to
d36401b
Compare
crates/core/build.rs
Outdated
| use inflector::Inflector; | ||
|
|
||
| fn main() { | ||
| uniffi::generate_scaffolding("src/lib.udl").unwrap(); |
There was a problem hiding this comment.
I guess you just ignored my input on this one. There are macros for this now; you're doing this in an outdated and harder to maintain way
crates/core/src/ffi/mod.rs
Outdated
| error: *mut RustString, | ||
| ) -> support::RustResult { | ||
| match dom::Document::parse_fragment_json(text.to_str()) { | ||
| match dom::Document::parse_fragment_json(text.to_str().to_string()) { |
There was a problem hiding this comment.
There's really no need to use owned strings here
KronicDeth
left a comment
KronicDeth
left a comment
There was a problem hiding this comment.
There's some commented out code that should be removed, but otherwise everything looks fine.
Was there a reason you went with uniffi.toml type definitions instead of using the proc-macros from newer uniffi?
...k/core/src/androidTest/java/org/phoenixframework/liveview_jetpack/ExampleInstrumentedTest.kt
Show resolved
Hide resolved
...native-core-jetpack/core/src/test/java/org/phoenixframework/liveview_jetpack/DocumentTest.kt
Show resolved
Hide resolved
simlay
force-pushed
the
simlay/34-uniffi-for-ffi
branch
from
26cb151 to
f233919
Compare
* Replace github url * Add pull_request trigger to CI --------- Co-authored-by: simlay <simlay@users.noreply.github.com> Co-authored-by: Sebastian Imlay <sebastian.imlay@gmail.com>
* Replace github url * Add pull_request trigger to CI --------- Co-authored-by: simlay <simlay@users.noreply.github.com> Co-authored-by: Sebastian Imlay <sebastian.imlay@gmail.com>
author Sebastian Imlay <sebastian.imlay@gmail.com> 1701222784 -0500 committer Sebastian Imlay <sebastian.imlay@gmail.com> 1701222784 -0500 * Replace github url * Add pull_request trigger to CI * Rename Node::Element to Node::NodeElement * swift and kotlin builds * Add CI workflows for swift and kotlin --------- Co-authored-by: simlay <simlay@users.noreply.github.com> Co-authored-by: Sebastian Imlay <sebastian.imlay@gmail.com> Co-authored-by: May Matyi <may@matyi.net>
simlay
force-pushed
the
simlay/34-uniffi-for-ffi
branch
from
f233919 to
ac57a02
Compare
Ideally this will close #34.
I'm trying outI've added the steps fromcargo-swiftusingcargo swift package -p ios -p macos -n LiveViewNativeCorecargo-swiftinto ourMakefile.toml.