Feliz: Question: Feliz.ElmishComponents vs Feliz.UseElmish

Então Feliz.ElmishComponents não é mais muito útil e é anterior a Feliz.UseElmish . A razão para isso é que originalmente Feliz.ElmishComponents era um componente baseado em classe, que reescrevi como um componente de função. Um pouco depois, percebemos que, se for um componente de função, é trivial apenas convertê-lo em um gancho. É assim que Feliz.UseElmish surgiu. Portanto, agora Feliz.ElmishComponents é realmente apenas um componente de função que chama o gancho. Na verdade, se você olhar para o projeto de Feliz.ElmishComponents verá que agora é

Muito obrigado, Cody !!! Portanto, se entendi corretamente, Feliz.UseElmish é o padrão agora.

Sim, ainda temos Feliz.ElmishComponents perto para não quebrar as pessoas. Você pode considerá-lo obsoleto.

Perfeito! Obrigado novamente!

Se estiver "obsoleto", pode ser uma boa ideia marcá-lo como "Obseleto" e redirecionar as pessoas para a API recomendada.

O que você acha?

Sim, estamos apenas discutindo com colegas da equipe F # que devemos fazer RP para a documentação (talvez com link para este problema)

Ok, eu fiz isso aqui - https://github.com/Zaid-Ajaj/Feliz/pull/264

Existe algum cenário típico em que você escolheria um em vez de outro? Adoro a facilidade de uso do Feliz.UseElmish e só receio estar faltando algo ainda mais legal aqui. 😄

Oi Roman, boa pergunta!

A diferença, como Cody mencionou, é que Feliz.UseElmish é escrito com ganchos em oposição a uma implementação de componente completa de Feliz.ElmishComponents .

No entanto, essa não é toda a história, porque Feliz.UseElmish também segue a _semântica do gancho_ quando se trata da reinicialização do componente pelo uso da matriz de dependência como o último argumento, o que é uma grande diferença de Feliz.ElmishComponents que não faz isso onde a reinicialização era hacky: criando chaves de componentes exclusivas a partir da entrada, caramba!

Feliz.UseElmish também pode ser combinado com outros ganchos, como assinaturas no mesmo componente.

O que quero dizer com "reinicialização"? Bem, imagine que você esteja carregando o componente de perfil de usuário com base nas alterações de URL da seguinte maneira:

#/user=profile/{userId} -> UserProfile { UserId = userId }

Basicamente, queremos reinicializar o componente UserProfile (chamando init para redefinir o estado) quando a entrada UserId muda:

type UserProfileProps = { UserId : int }

let UserProfile = React.functionComponent("UserProfile", fun (props: UserProfileProps) -> 
  let state, dispatch = React.useElmish(init props.UserId, update, [| props.UserId |])
  Html.h1 (sprintf "UserProfile(UserId=%d)" props.UserId)
)

// later on application  entry: 

React.router [
  router.onUrlChange (parseUrl >> UrlChanged >> dispatch) 
  router.children [
     match state.CurrentUrl with
     | [ "user-profile"; Route.Int userId ] -> UserProfile { UserId = userId }
     | _ -> Html.h1 "Not found" 
  ]
]

Como fornecemos o array de dependência [| props.UserId |] para o gancho (terceiro argumento para o gancho), o componente será atualizado automaticamente e chamará init novamente para redefinir o loop de despacho do Elmish. Isso é o que queremos porque init era uma função da entrada props.UserId então queremos chamá-la novamente quando os adereços dos componentes mudarem.

Quando nem a função init nem a função update requerem entrada adicional das propriedades do componente, você simplesmente fornece uma matriz de dependência vazia:

let state, dispatch = React.useElmish(init, update, [| |])

Isso normalmente é usado para componentes que não precisam de entrada de fora, como o componente de entrada do aplicativo.

Pode ser um pouco complicado se acostumar com a matriz de dependência, mas eles fazem muito sentido, leia mais sobre isso em Acionando um efeito condicionalmente a partir dos documentos de gancho.

Dica final: Feliz.UseElmish é realmente poderoso porque fornece um loop de despacho elmish completo, da mesma forma que você está acostumado com os aplicativos elmish tradicionais. No entanto, configurar tipos para o estado e as mensagens pode ser um pouco demais quando seus componentes são simples. Você precisa de algumas bandeiras estaduais? Então, algumas variáveis ​​de estado com React.useState podem ser suficientes. Você precisa buscar e renderizar alguns dados sem interação adicional? Então React.useDeferred pode resolver o problema. Eu irei para Feliz.UseElmish para páginas complicadas que têm muitos eventos e muita interação de uso.

Uau, a resposta típica de Zaid. 😄 Você deveria começar a ensinar essas coisas, cara! Eu posso finalmente entender. Obrigado novamente! ❤️