How to implement "borrowed props" in dioxus 0.5?

[bluenote10]

Apparently older versions of dioxus had owned vs borrowed props, but version 0.5 removed the "borrowed props". The migration guide mentions that ReadOnlySignal can be used to approximate borrowed props.

So far, my attempts at using ReadOnlySignal to get real borrowed props were not successful. Consider for instance the following example. Let's say our original code is:

#[component]
fn SomeComponent() -> Element {
    let entries = use_signal(|| vec!["foo".to_string(), "bar".to_string(), "baz".to_string()]);
    rsx! {
        div {
            for entry in entries.iter() {
                div { "{entry}" }
            }
        }
    }
}

Imagine our logic to render an entry gets more complicated than a single div. Then it would feel naturally to slightly refactor the code so move the (potentially verbose/messy) entry rendering into a separate function. Something like this:

#[component]
fn Entry(entry: ReadOnlySignal<String>) -> Element {
    rsx! {
        div { "{entry}" }
    }
}

#[component]
fn SomeComponentRefactored() -> Element {
    let entries = use_signal(|| vec!["foo".to_string(), "bar".to_string(), "baz".to_string()]);
    rsx! {
        div {
            for entry in entries.iter() {
                // How to get a borrowed prop, i.e., how to avoid the `.clone()`?
                Entry { entry: entry.clone() }
            }
        }
    }
}

This is where I would like to use a borrowed prop for Entry. I.e., I would like to apply such a refactoring without having an impact on performance / memory usage. Essentially I would like the Entry render function to just take a entry: &str, but that doesn't compile. Surprisingly, using the ReadOnlySignal also requires to use .clone() at the call site, which basically means that I could as well go for fn Entry(entry: String) -> ... as well, no?

How can I factor out such small "render helper components" without the need for owning / clone?

(In this example the clone() on a String isn't particularly costly, but if these "entries" are more heavy-weight having to clone them everywhere feels pretty bad.)