Comments (5)
Really appreciate all your responses! @Sajjon our minimum deployment is iOS 17 so that's a great solution. Excited to check out TCA and your app I wasn't familiar with TCA. I'll leave the issue open until at least tomorrow to allow members of the UniFFI team to share their thoughts on your suggestions.
from uniffi-rs.
Foremost we don't have any UDL spelling nor proc-macro for binding language specific settings for certain types. It would be very nice to have though! E.g. being able to express mutable/immutable stored properies on certain Swift types, and not catch em all, like we have today. Maybe @mhammond or @bendk can share some thoughts about that specifically...
We'd probably prefer to keep things which are language-specific like that in uniffi.toml
for as long as we can - eg, you would list those types there and it would influence the binding generator. Expressing this inside proc-macros would be both tricky (because we don't really have a way to carry arbitrary metadata from proc-macros all the way to the scaffolding generation) and it seems like it would become unwieldy if all languages ended up with their own set of custom things. That said though, we do try and be pragmatic.
from uniffi-rs.
Answered here, to be taken with a huge grain of salt:
@cadnza What is the convention for writing SwiftUI code with UniFFI with regard to having a view update when a field in a UniFFi Interface / rust struct changes?
@GraniteLake As far as I understand—first pointing out how wide and varied my lack of experience is with this—the way it's usually done is by writing an intermediary stuct/class in Swift that wraps UniFFI's class and adds SwiftUI's property wrappers and macro annotations. As far as how you get UniFFI to update the struct based on those wrappers and annotations, I'm not sure, but something along those lines is what I've been seeing going through other peoples' code.
from uniffi-rs.
I think @Sajjon has some interest/knowledge here?
from uniffi-rs.
Hey! There are several dimension to using UniFFI and SwiftUI; let me start by trying to reduce the scope a bit...
What is your minimum deployment target? If you can target iOS 17, you can simply write one wrapping model per screen, lets call it ViewModel, which is a class and annotate it with @Observable
macro . Which does not require its stored properties to have been marked with anything IIRC. So you can use UniFFI exported classes (or enums / srructs) as stored properties in this ViewModel.
This "solves" your issue completely without any changes needed to UniFFI.
If you need to target lower than iOS 17, you can employ the same technique with PointFrees Perception framework.
It might be interesting to explore possibilities to in Rust with UniFFI mark a uniffi::Object
to be marking the Swift class with @Observable
, but it being iOS 17+ we would need to wrap it with conditional compilation. We would also need to mark the generated swift file with #canImport(Observation)
because it is not available for Linux.... so there are several missing pieces and challenges in doing so.
EDIT [clarification]: Even if we (conditionally for iOS/macOS etc) could I don't think we should "blanket mark" all classes with @Observable
, it generates quite a bit of code, and for large classes in performance critical code one might not want said classes to grow even more. So best if we could make it possible - a new syntax - for UniFFI devs to tell UniFFI to mark specific classes with it.
Foremost we don't have any UDL spelling nor proc-macro for binding language specific settings for certain types. It would be very nice to have though! E.g. being able to express mutable/immutable stored properies on certain Swift types, and not catch em all, like we have today. Maybe @mhammond or @bendk can share some thoughts about that specifically...
If you are not using/required to use "vanilla SwiftUI" - whatever that means, since there is no clear standard; why I'm a huge fan of opinionated TCA by PointFree too - finally a standard! But I'm digressing... I was gonna say that I've recently managed to POC with TCA and SharedState with UniFFI.. Big PR... TL;DR; my app is completely driven by UniFFI, an object (swift class) for which I have a singleton, lets call it App
. Hosts (iOS TCA+SwiftUI apps / Android Kotlin app) implement "Drivers" which are UniFFI traits which App uses to make use of ""peripherals"" on the host: networking (URLSession), file IO, unsafe storage (UserDefaults), secure storage (keychain), and "EventBus" (AsyncPassthroughSubject) with which App
can emit "notifications" Rust side, with which I've implemented a custom PersistenceKey being the building block for @SharedReader
in TCAs state - which is @ObservableState
- TCAs value semantics analogue counterpart to @Observable
.
from uniffi-rs.
Related Issues (20)
- Crates.io shows 0.27.2 but the associated tag doesn't exist HOT 3
- Advice on creating external bindings for a comment type system only HOT 3
- Some old docs 404s HOT 1
- How to share a reference to a struct with UniFFI? HOT 3
- Support for `Option<&T>` HOT 1
- Support for projects not using `cargo` HOT 1
- Workspace broken | UniFFI generates invalid Swift & Python bindings HOT 9
- Design and agree on a 1.0 FFI HOT 4
- Use C structs/tagged unions for Records/Enums HOT 2
- Store return values in RustCallStatus
- Using proc-macros for constructor requires Arc<Self> HOT 4
- Accessing Vec<u8> in swift HOT 2
- Use a single buffer for all data
- Better Buffer packing
- Use the `FfiValue` type for all arguments HOT 1
- `HandleAlloc::clone_handle` and `consume_handle` should be marked unsafe HOT 3
- Rust pointers can have both even and odd addresses HOT 4
- `RustCallStatus::error_buf` should be `ManuallyDrop`, not `MaybeUninit`?
- Add implemented traits to generated code, or add extension? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uniffi-rs.