Feliz: Question : Happy.ElmishComponents contre Happy.UseElmish

Donc Feliz.ElmishComponents n'est plus très utile et est antérieur à Feliz.UseElmish . La raison en est qu'à l'origine, Feliz.ElmishComponents était un composant basé sur une classe, que j'ai réécrit en tant que composant de fonction. Un peu plus tard, nous avons réalisé que s'il s'agit d'un composant de fonction, il est trivial de simplement le convertir en un hook. C'est ainsi qu'est né Feliz.UseElmish . Alors maintenant, Feliz.ElmishComponents n'est en fait qu'un composant de fonction qui appelle le hook. En fait, si vous regardez le projet pour Feliz.ElmishComponents vous verrez qu'il est petit maintenant .

Merci beaucoup Cody !!! Donc, si j'obtiens i correctement, Feliz.UseElmish est celui par défaut, en ce moment.

Oui, nous avons encore pour la plupart des Feliz.ElmishComponents autour pour ne pas casser les gens. Vous pouvez le considérer comme obsolète.

Parfait! Merci encore!

S'il est "obsolète", il peut être judicieux de le marquer "obsolète" et de rediriger les utilisateurs vers l'API recommandée.

Qu'en penses-tu?

Oui, nous discutons juste avec des collègues de l'équipe F# que nous devrions faire des relations publiques avec la documentation (peut-être avec un lien vers ce problème)

Ok, je l'ai fait ici - https://github.com/Zaid-Ajaj/Feliz/pull/264

Existe-t-il des scénarios typiques dans lesquels vous choisiriez l'un plutôt qu'un autre ? J'aime la facilité d'utilisation de Feliz.UseElmish et je crains juste de manquer quelque chose d'encore plus cool ici. ??

Salut Romain, bonne question !

La différence, comme Cody l'a mentionné, est que Feliz.UseElmish est écrit avec des crochets par opposition à une implémentation complète des composants de Feliz.ElmishComponents .

Cependant, ce n'est pas toute l'histoire, car Feliz.UseElmish suit également la _sémantique du crochet_ en ce qui concerne la réinitialisation des composants en utilisant le tableau de dépendances comme dernier argument, ce qui est une grande différence par rapport à Feliz.ElmishComponents qui ne fait pas ça là où la réinitialisation était bidon : créer des clés de composant uniques à partir de l'entrée, beurk !

Feliz.UseElmish peuvent également être combinés avec d'autres hooks comme des abonnements dans le même composant.

Qu'est-ce que j'entends par « réinitialisation » ? Eh bien, imaginez que vous chargez le composant de profil utilisateur en fonction des modifications d'URL comme suit :

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

Fondamentalement, nous voulons réinitialiser le composant UserProfile (en appelant init pour réinitialiser l'état) lorsque l'entrée UserId change :

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" 
  ]
]

Étant donné que nous fournissons le tableau de dépendances [| props.UserId |] au hook (troisième argument du hook), le composant se rafraîchira automatiquement et appellera à nouveau init pour réinitialiser la boucle de répartition Elmish. C'est ce que nous voulons car init était une fonction de l'entrée props.UserId , nous voulons donc l'appeler à nouveau lorsque les accessoires des composants changent.

Lorsque ni la fonction init ni la fonction update ne nécessitent une entrée supplémentaire des props du composant, vous fournissez simplement un tableau de dépendances vide :

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

Ceci est généralement utilisé pour les composants qui n'ont pas besoin d'entrée de l'extérieur, comme le composant d'entrée de l'application.

Il peut être un peu difficile de s'habituer au tableau de dépendances, mais ils ont beaucoup de sens, en savoir plus à ce sujet dans Déclenchement conditionnel d'un effet à partir de la documentation du crochet.

Dernier conseil : Feliz.UseElmish est vraiment puissant car il vous offre une boucle de répartition elmish à part entière de la même manière que vous êtes habitué avec les applications elmish traditionnelles. Cependant, la configuration des types pour l'état et les messages peut être un peu trop lourde lorsque vos composants sont simples. Avez-vous besoin de quelques drapeaux d'État? Ensuite, quelques variables d'état avec React.useState pourraient suffire. Avez-vous besoin de récupérer et de restituer certaines données sans autre interaction ? Alors React.useDeferred pourrait faire l'affaire. J'opterai pour Feliz.UseElmish pour les pages compliquées qui ont de nombreux événements et beaucoup d'interactions d'utilisation.

Wow, la réponse typique de Zaid. Tu devrais commencer à enseigner ces choses, mec ! Je peux enfin comprendre. Merci encore! ️