Controlled input loses focus when re-rendered

[ChocolateLoverRaj]

One annoying thing with Leptos that doesn't happen in React is that controlled inputs lose focus when re-rendered. This is my code:

use leptos::*;

#[component]
pub fn Input() -> impl IntoView {
    let (name, set_name) = create_signal(Some("Controlled".to_string()));

    view! {
        {move || {
            name.get()
                .map(|name| {
                    view! {
                        <input
                            type="text"
                            on:input=move |ev| {
                                set_name(Some(event_target_value(&ev)));
                            }

                            // the `prop:` syntax lets you update a DOM property,
                            // rather than an attribute.
                            prop:value=name
                        />
                    }
                })
        }}
    }
}

Every time I type something, the input loses focus and I have to click on it again to type another key. Here are some solutions I found

Solution	Why it's not ideal
Use an uncontrolled input	The "source of truth" might be in the app state somewhere and it should be always in sync with the input
Use <Show />	Need to call unwrap on the Option<String>
Memoize is_some instead of using match directly on Option<String>	Need to call unwrap on the Option<String>

Is this a limitation of Leptos? Does anyone have ideas on ways that components can have control flow using match without re-rendering, or not lose focus when an input is rerendered?

[gbj]

This is not the right way to do things. Take a look at this, instead:

#[component]
pub fn Input() -> impl IntoView {
    let (name, set_name) = create_signal(Some("Controlled".to_string()));

    view! {
        <input
            type="text"
            on:input=move |ev| {
                set_name(Some(event_target_value(&ev)));
            }
            prop:value=move || name().unwrap_or_default()
        />
        <hr/>
        <pre>{move || format!("{:?}", name())}</pre>
        <button on:click=move |_| set_name(None)>"Clear"</button>
    }
}

React and Leptos work very differently.

With React's virtual DOM, you always pay the medium-sized cost of virtual DOM reconciliation. Leptos works directly with actual DOM nodes: there is no diffing overhead beyond what it tells you to do.

But what you are telling it to do in your example is,

1. every time name changes, then
2. if it's Some(name),
3. create a new <input> and assign the value of name to the value property on the <input>
4. and replace the previous <input> with the new <input>

i.e., by putting a reactive closure around the entire thing, you are causing the entire thing to rerender -- not a React virtual-DOM "render," but an actual DOM rendering, which is why it loses focus -- it is actually a different DOM element.

Because there is no virtual DOM, you never pay the cost of a virtual DOM. But you also need to make sure that you make push the actual reactive changes to the "leaves" of the view tree.

Note that in the rewritten version, I went for prop:value=move || name().unwrap_or_default() — this could have simply been prop:value=name except that setting value to undefined in the DOM sets it to the string "undefined", because... JavaScript is a little cursed.

[ChocolateLoverRaj]

Would this be a nicer solution that works better with Rust match?

trait CreateSignalOptionExt<T> {
    fn create_signal_option(self) -> Option<Signal<T>>;
}

impl<T: Clone> CreateSignalOptionExt<T> for ReadSignal<Option<T>> {
    fn create_signal_option(self) -> Option<Signal<T>> {
        let is_some = create_memo(move |_| self.get().is_some());
        match is_some() {
            true => Some(Signal::derive(move || self.get().unwrap())),
            false => None,
        }
    }
}

#[component]
fn App() -> impl IntoView {
    let (name, set_name) = create_signal(Some("Controlled".to_string()));

    view! {
        {move || match name.create_signal_option() {
            Some(name) => {
                view! {
                    <input
                        type="text"
                        on:input=move |ev| {
                            set_name(Some(event_target_value(&ev)));
                        }
                        prop:value=name
                    />
                    <p>"Name is: " {name}</p>
                }.into_view()
            }
            None => {
                view! {
                    <>No name</>
                }.into_view()
            }
        }}
    }
}

This example fixes the problem of the input re-rendering btw.

[gbj]

Yes, although note that you can use the <Show/> component to do exactly that same kind of memoized check -- in fact that's all it does:

#[component]
pub fn App() -> impl IntoView {
    let (name, set_name) = create_signal(Some("Controlled".to_string()));

    view! {
        <Show when=move || name.with(Option::is_some)
            fallback=|| "No name"
        >
            <input
                type="text"
                on:input=move |ev| {
                    set_name(Some(event_target_value(&ev)));
                }
                prop:value=name
            />
            <p>"Name is: " {name}</p>
            <button on:click=move |_| set_name(None)>Clear</button>
        </Show>
    }
}

Two other small notes, just as the maintainer 😄

1. You can simplify your view! { {move || to simply be move || — i.e., remove the wrapping view! macro. I like this both because it will make your compile times a bit faster, and your code indentation a bit less, but also because it shows clearly that the view macro isn't magic. It will just expand that block to exactly what it is -- the function.
2. Same thing with <>No name<> -- this one can just be None => "No name", as all that the fragment does here is return the string.

[ChocolateLoverRaj]

<Show /> results in a different type for the name variable though. When using Show, the type is ReadSignal<Option<String>>. When using my create_signal_option function, the type is Signal<String>, which lets you use the string without calling unwrap. I think a create_signal_option function would be more convenient to use because of the type checking.

[gbj]

Totally fair!