Antipadrões

Este exemplo mostra o que não fazer e fornece uma razão pela qual um determinado padrão é considerado um "AntiPattern". A maioria dos antipadrões são considerados errados por motivos de desempenho ou por prejudicar a reutilização do código.

Fragmentos Aninhados Desnecessariamente

Os fragmentos não montam um elemento físico no DOM imediatamente, então o Dioxus deve recorrer a seus filhos para encontrar um nó DOM físico. Este processo é chamado de "normalização". Isso significa que fragmentos profundamente aninhados fazem o Dioxus realizar um trabalho desnecessário. Prefira um ou dois níveis de fragmentos/componentes aninhados até apresentar um elemento DOM verdadeiro.

Apenas os nós Componente e Fragmento são suscetíveis a esse problema. O Dioxus atenua isso com componentes fornecendo uma API para registrar o estado compartilhado sem o padrão Context Provider.

#![allow(unused)]
fn main() {
    // ❌ 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!" }
    ))
}

Chaves do Iterador Incorretas

Conforme descrito no capítulo de renderização condicional, os itens da lista devem ter keys exclusivas associadas aos mesmos itens nas renderizações. Isso ajuda o Dioxus a associar o estado aos componentes contidos e garante um bom desempenho de diferenciação. Não omita as keys, a menos que você saiba que a lista é estática e nunca será alterada.

#![allow(unused)]
fn main() {
    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}" }
            ))
        }
    })
}

Evite Mutabilidade Interior em Props

Embora seja tecnicamente aceitável ter um Mutex ou um RwLock nos props, eles serão difíceis de usar.

Suponha que você tenha um struct User contendo o campo username: String. Se você passar uma prop Mutex<User> para um componente UserComponent, esse componente pode querer passar o nome de usuário como uma prop &str para um componente filho. No entanto, ele não pode passar esse campo emprestado, pois ele só viveria enquanto o bloqueio do Mutex, que pertence à função UserComponent. Portanto, o componente será forçado a clonar o campo username.

Evite Atualizar o Estado Durante a Renderização

Toda vez que você atualiza o estado, o Dioxus precisa renderizar novamente o componente – isso é ineficiente! Considere refatorar seu código para evitar isso.

Além disso, se você atualizar incondicionalmente o estado durante a renderização, ele será renderizado novamente em um loop infinito.