Warning

This post was published 95 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Event listeners, ReactiveUI and assets

I'll be brief. For who's familiar to either React.js or Dioxus.rs, let's say I have:

#[ru::component]
fn Component1() -> ru::Node {
    let mut x = ru::use_state::<f64>(|| 0.);
    let mut btn = ru::use_ref::<Option<whack::UiComponentRef>>(|| None);

    ru::use_effect!({
        whack::evt!(comp=btn().unwrap(), click, |e| {
            // This is just an example; we could
            // just use `click&={}` in ru::xn!
            // to handle the event as well
            x += 1.;
        });

        whack::easy_timeout!({
            x += 1.;
        }, whack::Duration::from_secs(1));
    });

    ru::xn! {
        <w:VGroup gap={5}>
            <w:Label variant="heading">"{x}"</w:Label>
            <w:Button bind={btn}>increase</w:Button>
        </w:VGroup>
    }
}

I've not implemented that yet, but I've a plenty of questions:

• How does Dioxus support mut states (signals), making it so the lambdas may use them and at the same time the component may return a node reading the same states?
• How does Dioxus handle "optional" component properties? (Does everything a component has to receive have to be Option?)
  • As far as I know proc macros have no access to semantics...
• Anyway, how does Dioxus even know how to construct the component's properties struct without calling the component? (React.js+JSX returns a ReactNode which doesn't call the hook component directly). Is it doing some sort of reflection?
• My gfx::DisplayObject and whack::UiComponent structs should implement event listeners pretty much like the DOM; but I've not figured what's the best way to store their actual functions (Rc<RefCell<dyn FnMut(E)>>? but in that case it won't be possible to use the captured muts later?)

Assets

I've seen Dioxus also has a macro for embedding assets, but not statically at the final program, and rather externally, and may be loaded at runtime. That's something I wanted to have, as I support app:-schemed files which resolve to the installation's directory. This is useful for libraries which include many icons, which I may not want to put all into the RAM at once.

A proc macro that does this certainly has to write to somewhere in like OUT_DIR, but I'm wondering if OUT_DIR, when building a proc macro, is guaranteed to return the same OUT_DIR of the entry crates being built? Wondering because, say we're building with aarch64-linux-android... will the build script be built with this too? If not, then I guess OUT_DIR may be inconsistent.

1 post - 1 participant

Read full topic

🏷️ Rust_feed