Replies: 1 comment 2 replies
-
I think this doesn't fit with Bevy after looking at |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I wonder if it could make sense to have nodes (probably atomically-reference-counted) around UI entities because the existing use of spawning and unspawning commands supports no children operations, such as finding child by path (whether
../child_id/blah
), getting a child's path. Consider:..
and names@ViewModel(...) elementRef: ElementRef;
andelementRef.nativeElement
).I think this is a way to implement nodes in Rust with composition instead of traits for avoiding dynamic dispatch on complementary fields:
Summary:
Node
avoids contravariant methods. For example, ifset_foo
belongs toFoo
variant, generallyNode
doesn't define it.Node
implementsFrom<K>
(so a contravariant type can convert intoNode
by simply.into()
).syn
crate:markup!
,define_node!
anddefine_ui_component!
.define_node!
defines a node kind, which holds (node, data), inheriting everything from node, implicitlydefining
set_
methods for attributes used in themarkup!
macro. data is of the hiddenK__Internal
type.to::<K>
,try_into::<K>
and.is::<K>
are supported byNode
.Beta Was this translation helpful? Give feedback.
All reactions