Modèles d'interface utilisateur dans les langages fonctionnels

Je voudrais commencer à jouer avec ClojureScript, mais je suis perplexe sur certains points. Mon problème est ce qui est une bonne façon de gérer les changements d'état provenant de l'interaction avec l'utilisateur, lorsque vous essayez de travailler de manière fonctionnelle.

Permettez-moi de donner quelques exemples. Je pense aux applications qui s'exécutent dans le navigateur, mais je pense que le problème est plus général. Bien sûr, quelque chose va changer - le DOM au moins. Mais je voudrais savoir comment organiser le reste du code pour travailler avec des structures de données immuables.

1) Disons que je veux attacher certains événements à un objet DOM. Ce n'est pas difficile à faire d'une manière principalement fonctionnelle: lorsque vous créez le nœud, vous lui associez une carte de hachage avec les différents gestionnaires d'événements. Mais considérez le cas où vous utilisez la délégation d'événements. Ensuite, lorsque vous créez un nouveau nœud, vous pouvez attacher un gestionnaire d'événements à un nœud parent qui existe probablement déjà. Vous devrez donc modifier le hachage associé au nœud déjà existant.

2) Supposons que je conçois un module de saisie semi-automatique pour un champ de saisie. Chaque fois que l'utilisateur appuie sur une touche, je peux appeler un serveur pour obtenir les suggestions. C'est facile. Mais supposons maintenant que je veuille l'optimiser un peu. Si je connais tous les résultats correspondants, fooil est inutile de demander à nouveau tous les résultats correspondants foobar; Je peux simplement filtrer le premier. J'ai donc besoin de créer une sorte de cache. Ce cache sera mis à jour à chaque fois que l'utilisateur insère un nouveau mot qui n'est pas un sur-ensemble des mots précédemment saisis. Encore une fois: comment modéliser le cache? La manière la plus raisonnable semble être une carte de hachage mappant les mots aux résultats, mais elle devrait être modifiable.

Pouvez-vous suggérer des modèles qui faciliteraient l'intégration des changements dus à l'interaction de l'utilisateur dans une conception fonctionnelle?

functional-programming ui state

— Andrea
source

Rechercher "Programmation réactive fonctionnelle".

— dan_waterworth

Ce n'est pas tout à fait la même chose, mais avec les modèles XSLT (sans effets secondaires) qui correspondent aux événements DOM initiés par un utilisateur, nous sommes confrontés à un problème similaire dans Saxon-CE. La façon dont j'aime le voir est que l'utilisateur déclenche le changement d'état, pas le XSLT, donc c'est assez bien. La clé est de s'assurer que le code qui gère l'interaction avec l'utilisateur et les changements d'état ultérieurs est très distinct du reste.

— pgfearo

@pgfearo Avez-vous des conseils pour organiser le code afin que l'interaction utilisateur soit suffisamment séparée des autres?

— Andrea

Il n'y a pas de bon moyen de gérer les changements d'état lorsque vous travaillez de manière fonctionnelle, car la programmation fonctionnelle est sans état.

— Old Pro

@Old Pro: Ce n'est pas tout à fait correct. Alors que dans la programmation fonctionnelle, vous définissez un calcul en utilisant une application de fonction au lieu d'un effet secondaire, vous devez éventuellement enregistrer le résultat du calcul quelque part. L'objectif de FP est de restreindre l'utilisation de l'état au minimum alors qu'en programmation impérative, la transformation incrémentielle de l'état (par effets secondaires) est l'outil de base pour définir un calcul.

— Giorgio

Comme mentionné dans les commentaires, vous devriez rechercher «Programmation réactive fonctionnelle» et vous devriez également lire certains des articles sur http://prog21.dadgum.com/archives.html . Plus précisément, vous devriez probablement lire « Ne tombez pas amoureux de votre technologie », « Écrivez du code comme si vous veniez d'apprendre à programmer », « La programmation fonctionnelle ne fonctionne pas (et que faire à ce sujet) », et peut-être un quelques autres.

Il est pratiquement impossible d'éviter complètement la mutabilité et les effets secondaires. Même les programmeurs Haskell utiliseront de temps en temps unsafePerformIOpour sortir du paradigme purement fonctionnel, sans effets secondaires et statiquement typé pour faire certaines choses. Si vous vous lancez dans ce projet comme un exercice purement académique, allez-y et évitez autant que possible la mutabilité et les effets secondaires, mais si vous essayez de construire un produit utilisable dans un délai, aucun modèle ne vous sauvera.

— davidk01
source