Pattern di interfaccia utente in linguaggi funzionali


11

Vorrei iniziare a giocherellare con ClojureScript, ma sono perplesso su alcuni punti. Il mio problema è quello che è un buon modo per gestire i cambiamenti di stato derivanti dall'interazione dell'utente, quando cerchi di lavorare funzionalmente.

Vorrei fare un paio di esempi. Ho in mente applicazioni che girano nel browser, ma penso che il problema sia più generale. Naturalmente qualcosa cambierà, almeno il DOM. Ma vorrei scoprire come organizzare il resto del codice per lavorare con strutture di dati immutabili.

1) Dire che voglio associare alcuni eventi a qualche oggetto DOM. Questo non è difficile da fare in un modo principalmente funzionale: quando si crea il nodo, si allega una mappa hash con i vari gestori di eventi. Ma considera il caso in cui stai utilizzando la delega degli eventi. Quindi, quando si crea un nuovo nodo, è possibile collegare un gestore eventi a un nodo padre che probabilmente esiste già. Quindi dovresti cambiare l'hash associato al nodo già esistente.

2) Dire che sto progettando un modulo di completamento automatico per un campo di input. Ogni volta che l'utente preme un tasto, posso effettuare una chiamata a un server per ottenere i suggerimenti. Questo è facile. Ma ora supponiamo che io voglia ottimizzarlo un po '. Se conosco tutti i risultati corrispondenti foonon ha senso chiedere di nuovo tutti i risultati corrispondenti foobar; Posso solo filtrare il primo. Quindi ho bisogno di creare un qualche tipo di cache. Questa cache verrà aggiornata ogni volta che l'utente inserisce una nuova parola che non è un superset delle parole precedentemente immesse. Ancora: come modellare la cache? Il modo più ragionevole sembra essere una mappa hash che associa le parole ai risultati, ma dovrebbe essere mutabile.

Puoi suggerire alcuni schemi che faciliterebbero l'incorporazione delle modifiche dovute all'interazione dell'utente in un design funzionale?


4
Cerca "Programmazione reattiva funzionale".
dan_waterworth,

Non è esattamente la stessa cosa, ma con i modelli XSLT (senza effetti collaterali) che corrispondono agli eventi DOM avviati da un utente, affrontiamo un problema simile in Saxon-CE. Il modo in cui mi piace vederlo è che l'utente sta innescando il cambiamento di stato, non l'XSLT, quindi è un po 'Ok. La chiave è garantire che il codice che gestisce l'interazione dell'utente e i successivi cambiamenti di stato sia molto separato dal resto.
pgfearo,

@pgfearo Hai qualche consiglio su come organizzare il codice in modo che l'interazione dell'utente sia mantenuta abbastanza separata dal resto?
Andrea

Non c'è un buon modo per gestire i cambiamenti di stato quando si lavora in modo funzionale, poiché la programmazione funzionale è senza stato.
Old Pro,

3
@ Vecchio Pro: questo non è del tutto corretto. Mentre nella programmazione funzionale definisci un calcolo usando l'applicazione della funzione anziché l'effetto collaterale, alla fine devi salvare il risultato del calcolo da qualche parte. L'obiettivo di FP è di limitare al minimo l'uso dello stato, mentre nella programmazione imperativa la trasformazione incrementale dello stato (per effetti collaterali) è lo strumento di base per la definizione di un calcolo.
Giorgio,

Risposte:


3

Come menzionato nei commenti, dovresti cercare "Programmazione reattiva funzionale" e leggere anche alcuni dei post su http://prog21.dadgum.com/archives.html . Più precisamente dovresti probabilmente leggere " Non innamorarti della tua tecnologia ", " Scrivi codice come hai appena imparato a programmare ", " La programmazione funzionale non funziona (e cosa fare al riguardo) ", e forse un pochi altri.

Evitare completamente la mutabilità e gli effetti collaterali è praticamente impossibile. Di tanto in tanto anche i programmatori Haskell potranno fare unsafePerformIOa meno del paradigma puramente funzionale, privo di effetti collaterali e tipicamente statico per fare determinate cose. Se stai intraprendendo questo progetto come un esercizio puramente accademico, vai avanti ed evita il più possibile la mutabilità e gli effetti collaterali, ma se stai cercando di costruire un prodotto utilizzabile entro una scadenza, nessun modello ti salverà.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.