From the perspective of Rust, the way SwiftUI propagates type information to establish the static view graph and simplify the diffing problem seems directly applicable to Rust, since it has a lot of the same sugar (`impl View` instead of `some View`) already
-
-
Replying to @jckarter
So in druid we use https://docs.rs/druid/0.3.1/druid/trait.Data.html … for this, and I think it's broadly similar to what you describe. But, since this is Twitter, now I'm going to say something controversial.
1 reply 0 retweets 1 like -
Replying to @raphlinus @jckarter
I think this model of making something look simple (this is just a reference to some data) and making it do something really complex and sophisticated behind the scenes is dangerous. It works well for small examples, but when things go wrong they can go really wrong.
2 replies 0 retweets 1 like -
Replying to @raphlinus
I tend to agree. However, just from witnessing the struggle within Apple to get folks onboard with the paradigm, sugar does goes a long way to making the jump for programmers familiar with immediate mode stuff easier.
2 replies 0 retweets 1 like -
Replying to @jckarter
I can well imagine. And you were dealing with a different set of constraints, so I'm not really criticizing your choices here.
1 reply 0 retweets 0 likes -
Replying to @raphlinus
If it helps, I can try to peel away at least one layer of magic. Views used to look like this: struct MyView: View { struct State { // state went here as an assoc type } // And a Binding was passed in explicitly func body(state: MuggleBinding<State>) -> some View {…
1 reply 0 retweets 1 like -
Replying to @jckarter @raphlinus
And the MuggleBinding, instead of using sugar, was more explicitly an opaque handle with a bundle of the value snapshot, and a function to produce Actions from updates: state.value // old value state.update { makeSomeChangeTo(&$0) } // turn a closure updating state into Action
1 reply 0 retweets 0 likes -
Replying to @jckarter @raphlinus
And you could use a WritableKeyPath (really just a Lens) to focus a binding to the state down to a binding to some subcomponent of it with an explicit state.focus(\.field) method as well.
1 reply 0 retweets 0 likes -
Replying to @jckarter @raphlinus
To hide the unfamiliar functional stuff more, we made it so that the state struct, as well as other environment state subscriptions, is automatically derived by reflection over the type layout. In Haskell you could probably do something similar using Generic and DerivingVia
1 reply 0 retweets 0 likes -
Replying to @jckarter @raphlinus
And the update syntax was made more direct by making it sort of an untyped algebraic effect handler. State reads and writes, although syntactically applied directly to the "property", have to access storage provided contextually by the framework, which turns writes into actions
1 reply 0 retweets 0 likes
Thanks for this additional detail, I find it very interesting.
-
-
Replying to @raphlinus @jckarter
Do you have any thoughts on the upcoming Android version of these ideas? https://developer.android.com/jetpack/compose there was a great talk about its internals recentlyhttps://www.youtube.com/watch?v=Q9MtlmmN4Q0 …
1 reply 0 retweets 0 likes -
You know, it's on my list to dive into Jetpack Compose internals, but I have not done so yet. There's a lot of really interesting activity out there, it's not easy to keep track of it all.
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.