Antipatterns

This example shows what not to do and provides a reason why a given pattern is considered an "AntiPattern". Most anti-patterns are considered wrong for performance or code re-usability reasons.

Unnecessarily Nested Fragments

Fragments don't mount a physical element to the DOM immediately, so Dioxus must recurse into its children to find a physical DOM node. This process is called "normalization". This means that deeply nested fragments make Dioxus perform unnecessary work. Prefer one or two levels of fragments / nested components until presenting a true DOM element.

Only Component and Fragment nodes are susceptible to this issue. Dioxus mitigates this with components by providing an API for registering shared state without the Context Provider pattern.

// ❌ Don't unnecessarily nest fragments
let _ = cx.render(rsx!(
    Fragment {
        Fragment {
            Fragment {
                Fragment {
                    Fragment {
                        div { "Finally have a real node!" }
                    }
                }
            }
        }
    }
));

// ✅ Render shallow structures
cx.render(rsx!(
    div { "Finally have a real node!" }
))

Incorrect Iterator Keys

As described in the dynamic rendering chapter, list items must have unique keys that are associated with the same items across renders. This helps Dioxus associate state with the contained components and ensures good diffing performance. Do not omit keys, unless you know that the list will never change.

let data: &HashMap<_, _> = &cx.props.data;

// ❌ No keys
cx.render(rsx! {
    ul {
        data.values().map(|value| rsx!(
            li { "List item: {value}" }
        ))
    }
});

// ❌ Using index as keys
cx.render(rsx! {
    ul {
        cx.props.data.values().enumerate().map(|(index, value)| rsx!(
            li { key: "{index}", "List item: {value}" }
        ))
    }
});

// ✅ Using unique IDs as keys:
cx.render(rsx! {
    ul {
        cx.props.data.iter().map(|(key, value)| rsx!(
            li { key: "{key}", "List item: {value}" }
        ))
    }
})

Avoid Interior Mutability in Props

While it is technically acceptable to have a Mutex or a RwLock in the props, they will be difficult to use.

Suppose you have a struct User containing the field username: String. If you pass a Mutex<User> prop to a UserComponent component, that component may wish to pass the username as a &str prop to a child component. However, it cannot pass that borrowed field down, since it only would live as long as the Mutex's lock, which belongs to the UserComponent function. Therefore, the component will be forced to clone the username field.

Avoid Updating State During Render

Every time you update the state, Dioxus needs to re-render the component – this is inefficient! Consider refactoring your code to avoid this.

Also, if you unconditionally update the state during render, it will be re-rendered in an infinite loop.