Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common components in different crate -> issue #2228

Closed
XavDesbordes opened this issue Apr 2, 2024 · 1 comment
Closed

Common components in different crate -> issue #2228

XavDesbordes opened this issue Apr 2, 2024 · 1 comment
Assignees
Milestone

Comments

@XavDesbordes
Copy link

XavDesbordes commented Apr 2, 2024

Dioxus 0.5.0. alpha 2
Linux
Full stack app

Hi,
Currently rewriting some app I had in TS into Rust.

I want to create many reusable components for my projects, so I've created them in a separate crate that I will import at will in different projects.

The issue lies in the fact that the router and #[component] don't seem happy:

error[E0277]: the trait bound `fn(common_html_components::components::modals::ModalProps) -> std::option::Option<dioxus_core::nodes::VNode> {common_html_components::components::modals::Modal}: dioxus::prelude::ComponentFunction<_, _>` is not satisfied
    --> src/interface/static_analysis.rs:1205:117
     |
91   | /                 rsx! {
92   | |                                     div { class: "d-flex justify-content-center", h1 { "Analyse statique" } }
93   | |                                     div { class: "d-flex flex-column",
94   | |                                             div { class: "d-flex justify-content-center flex-column" }
...    |
1205 | |                                                                                                                     Modal {
     | |                                                                                                                     ^^^^^ the trait `dioxus::prelude::ComponentFunction<_, _>` is not implemented for fn item `fn(ModalProps) -> Option<VNode> {Modal}`
...    |
1409 | |                                     }
1410 | |                             }
     | |_____________________________- required by a bound introduced by this call
     |
     = help: the trait `dioxus::prelude::ComponentFunction<std::rc::Rc<std::cell::Cell<dioxus::prelude::RouterConfig<interface::route::Route>>>>` is implemented for `interface::route::Route`
note: required by a bound in `dioxus::prelude::fc_to_builder`
    --> /home/.cargo/git/checkouts/dioxus-1e619ce595d3799d/9f280a8/packages/core/src/properties.rs:91:36
     |
91   | pub fn fc_to_builder<P, M>(_: impl ComponentFunction<P, M>) -> <P as Properties>::Builder
     |                                    ^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `fc_to_builder`



main.rs
interface.rs
---interface
-----route.rs
-----static_analysis.rs
-----dynamic_analysis.rs

route.rs:

use dioxus::prelude::*;

use crate::some_stuffs
...

#[derive(Clone, Routable, Debug, PartialEq, serde::Serialize, serde::Deserialize)]
pub(crate) enum Route {
        #[route("/")]
        Home {},
        #[route("/static")]
        StaticAnalysis {},
        #[route("/dynamic")]
        DynamicAnalysis {}
}

the other culprit, Modal, used in StaticAnalysis and co:

use dioxus::prelude::*;
...

#[component]

pub fn Modal(button_title: String, modal_title: String, modal_body: String, modal_ok: String, modal_close: Option<String>, color_type: ModalColorType) -> Element {
...
}

I think that the issue is my calling strategy:

 Modal {
        button_title: "{dummy_example}"
        modal_title: "{dummy_example}",
        modal_body: "{dummy_example}",
        modal_ok: "{dummy_example}",
        modal_close: None,
        color_type: ModalColorType::Blue
}

as described here, by the component macro that doesn't "like" the separate crate thing ?
I didn't have issue when it was in the same crate.

While the new Component is shorter and easier to read, this macro should not be used by library authors since you have less control over Prop documentation.
by prop documentation, you mean system registration or user facing documentation (that one shouldn't cause the issue above) ?

I really really like this component macro for the simplicity, so is there a way to make it work ?

Thanks!

@jkelleyrtp jkelleyrtp added this to the 0.6.0: Devtools milestone Apr 2, 2024
@ealmloff ealmloff self-assigned this Apr 4, 2024
@ealmloff
Copy link
Member

ealmloff commented Apr 4, 2024

I cannot reproduce an issue when importing a component created with the #[component] macro from another crate with dioxus 0.5.0. Here is my setup.

That error message is also very common if you have mismatched versions of dioxus between different crates. It could happen if you rely on the git version of dioxus in one crate and the 0.5 version in another crate or dioxus-router = "0.5" with dioxus = "0.4"

@ealmloff ealmloff closed this as not planned Won't fix, can't repro, duplicate, stale May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants