Bisogna migliorare la gestione degli errori in src/routes/index.svelte.

Attualmente gli errori possono essere forniti da due cose:

• yup che valida i campi
• strapi che ritorna 404 se l'email non esiste.

Al momento il field prende l'errore direttamente dallo store errors, che è controllato da yup e svelte-forms-lib.

Quando invece l'errore arriva da strapi, sostanzialmente si fa errors.set({ email: err.message });. Ovvero si sovrascrive lo store con il nuovo errore.

Questo però fa si che quando si clicca fuori dal field, l'errore sparisca.
L'ipotesi è che yup faccia, on blur, un nuovo controllo dei field e giustamente vede che è tutto apposto e leva l'errore.
Di conseguenza probabilmente bisogna cambiare il comportamento di handleChange o handleSubmit.

ps. Ci sarebbe anche da sistemare eventualmente il caso in cui strapi ritorni errori diversi da L'utente non esiste.

Potrebbe essere utile, quando si creano entità nei controller, aggiungere il campo createdBy.

La pagina login/password deve reindirizzare all'inserimento della mail nel caso non ci siano email e username in localstorage.

Gli utenti creati tramite l'iscrizione ad un corso, di default, non sono cercabili sul motore di ricerca di Join.

Vantaggi:

• evita che mille persone creino account per i corsi e poi la ricerca sia lentissima
• evita di cercare profili vuoti

Alla prima registrazione forse bisognerebbe chiedere all'utente se vuole farsi trovare oppure no.

Quando i field dei form sono validi
[ad esempio, quando in registrazione l'username selezionato è disponibile]
il field deve diventare verde.

Al momento, l'utente per eliminare il suo account deve fare richiesta al supporto, che elimina manualmente l'entità dal pannello di controllo.

ToDo

• Nel frontend, bisogna mettere nella pagina di utente la dicitura che spiega come effettuare l'eliminazione dell'account.
• Nel backend, bisogna mettere un check beforeDelete: se non è stata ancora emessa fattura non si può eliminare l'utente collegato nè tanto meno il pagamento. Nel caso in cui billingoption fosse me e si eliminasse l'utente, non ci sarebbe modo di risalire a email nome e cognome.

Nella cartella lib/components ci sono tanti componenti diversi, potrebbero essere organizzati in sottocartelle.
Anche lib, più in generale, potrebbe essere sistemata.

Comportamento atteso

1. Utente – Pagina profilo – L'utente mette le skill a caso, campo di testo libero. A mano a mano che si scrive c'è una search che aggiorna con i termini più simili.
2. Admin – Pagina skills – Si fa il merge delle skill duplicate o simili.
3. Utente – Home / Pagina profilo – Arriva la notifica del cambiamento avvenuto.

Sarebbe comodo far sì che il pulsante di submit di un corso resti disattivato fino al completamento (e validazione) del form

In alcuni form manca ancora la conferma della password inserita.
Questo problema va da risolvere a seguito a #3.

Problema

Attualmente, nel backend ci sono molti campi obbligatori che non sono ancora indicati come tali.
Come conseguenza di ciò, quando vengono generati i tipi, compare l'helper Maybe<T>.
E come conseguenza di ciò, per evitare alcuni errori di typescript, in molti casi è stato aggiunto as per forzare alcuni tipi.

Cosa fare

Quando, a seguito dell'issue #44, verranno sistemati i campi obbligatori bisognerà togliere tutti questi as.

Per una eventuale sicurezza, prima di andare in produzione ci si può assicurare che i campi che devono essere obbligatori siano marcati come tali nel backend.

Serve mettere una scadenza per le email di conferma di registrazione e recupero password?

Cose da fare:

• Salvare il nome dell'admin che approva l'iscrizione
• Aggiungere pulsanti che integrano le logiche di pulizia dei dati quando il corso finisce

Inoltre:

• Si potrebbe fare che puoi gestire le iscrizioni se e solo se sei stato segnato coordinatore di quel corso

Nella navbar all'intero dell'applicazione, ascondere il logout dentro un dropdown, in modo tale da evitare misclick quando l'utente clicca sul suo profilo. Oppure trovare un'altra soluzione che in generale eviti misclick.

Mostrare quali sono i parametri per la password ed eventualmente fare una checklist che si completa o magari far vedere anche una "strength bar".

Sarebbe bello rendere il form indipendente e riutilizzabile in altri progetti.
Per farlo, servirebbe che:

• si possa passare al form la schermata di caricamento che compare quando il form è nello stato submitting. Un modo per farlo potrebbe essere aggiungere un secondo slot al form, nel quale l'utente possa mettere i suoi componenti per il caricamento.
• passare le icone come warning o close al form. Si potrebbe fare che il form di suo ha delle icone, ma l'utente può passare le proprie.

Aggiungere pulsanti per mostrare password, cancellare campo (utile per mobile) e simili. Eventualmente aggiungere anche un'icona?

Come gestire la scadenza del JSON Web Token?

Per una questione di usabilità, è importante che il messaggio di errore venga mostrato in corrispondenza del field dove c'è l'errore.

L'errore deve essere mostrato con:

• colore rosso
• icona di errore

La validazione dei campi richiede una libreria che deve essere individuata.

La validazione deve avvenire:

• on:blur
• (possibilmente) in seguito a inattività

Qualche reference:

• https://github.com/chainlist/svelte-forms
• https://blog.logrocket.com/form-validation-in-svelte/
• https://validatejs.org/
• https://pristine.js.org/

Quando un utente che è loggato prova ad andare alla pagina di iscrizione di un corso a cui è già iscritto, dovrebbe essere reindirizzato.

Dove viene reindirizzato?

• Alla pagina dell'iscrizione (ma servirà una pagina dell'iscrizione? Probabilmente no)
• Alla pagina del corso
• [altre opzioni?]

In più più, potrebbe essere utile mostrare un box da qualche parte che dice qualcosa tipo "Sei già iscritto a questo corso, trovi qui la tua iscrizione".

Trovare un unico sistema per gestire la spaziatura:
ad esempio i link per tornare indietro in Password Reset o Register

Far sì che il login verifichi prima l'email, e successivamente la password.
Questo, allo scopo di inviare il form e ricevere indietro l'errore "Identifier or password not correct", che a livello di UX non è il massimo.

Sistema nomenclatura variabili css.

Ci sono alcuni campi con validazione asincrona, come in routes/register/index.svelte.
C'è il problema che se c'è un errore nel server, il messaggio di errore mostrato non è quello del server ma il messaggio che dovrebbe comparire quando il campo è invalido.

Cose da fare:

Frontend:

• Deve sparire il link "iscriviti" quando il tempo per le iscrizioni passa
• Se si va direttamente sulla pagina di iscrizione il form non ci deve essere e al suo posto va messo un messaggio "le iscrizioni al corso sono chiuse".

Backend

• Aggiungere policy che blocca l'accesso all'endpoint enroll

Fare revisione della gestione degli errori nei controller e nelle policies.
Forse bisogna aggiungere qualche try...catch, ad esempio per verificare cosa ritornano entityservice o query.

Bisogna fare in modo che quando un form ha fatto il submit dei dati ed è in attesa di ricevere risposta, compare lo spinner di caricamento.

In teoria non si dovrebbe nè poter cliccare nè cambiare pagina, nè editare i field.

Tuttavia, quando il caricamento finisce per un errore, il form dovrebbe avere i campi già compilati da prima e mostrare l'errore.

Bisognerebbe fare revisione su questa funzione, che si occupa di effettuare richieste POST.
Il senso di sta funzione è gestire gli errori che vengono da Strapi, per poi effettivamente mostrarli nel frontend.

L'ho copiata e in parte modificata da un tutorial su youtube (circa 23:30).

Funziona, ma credo si potrebbe ripulire e sistemare. (Forse ho un po' esagerato con i try... catch).

L'utente non deve poter inserire come password nuova una uguale a quella vecchia.

Per ogni query di GraphQL bisognerebbe creare un tipo corrispondente in typescript.
Vantaggi:

• VSCode non segna errori
• C'è l'intellisense

Al momento, la pagina che raccoglie le iscrizioni dell'utente è molto semplice: mostra le iscrizioni attive (cioè iscrizioni non rifiutate per corsi che devono ancora partire, fino al loro termine); e poi tutte le iscrizioni non attive.

Ci sarebbero diversi modi per migliorare la pagina:

• Le card delle iscrizioni potrebbero avere un link ai corsi
• Le card con iscrizioni per cui bisogna effettuare il pagamento riportare il link al pagamento
• Le card pagate avere il link alla fattura (?)

etc etc.

Bisogna riflettere su come gestire la rimozione dei dati di pagamento al termine del corso:

• vengono eliminati in automatico dopo un po'?
• l'admin del corso li elimina quando vengono emesse le fatture?

Bisogna sistemare il messaggio di errore che arriva quando nel login la password è sbagliata.

Potrebbe essere necessario aggiungere un ENUM del tipo

• iscrizioni aperte
• corso approvato
• corso in svolgimento
• corso non partito
• corso concluso

(Magari alcune si ripetono, si può sintetizzare)

Al momento, la libreria utilizzata per le query GraphQL non ha la cache. Non è un problema, ma potrebbe tornare utile in futuro.

A seguito di #3, far comparire messaggio di errore quando l'username è simile.
Attualmente esce scritto "email is already taken" quando in realtà l'errore è nell'username.

Migliorare ux/ui dei campi telefono, cap, partita iva, etc.

L'idea è che si possa costruire un campo con i singoli caratteri separati, un po' come i moduli da compilare a mano.
In questo modo:

• si capisce la lunghezza dell'input
• eventualmente: si può mostrare qual è la cella che contiene l'errore (faccio riferimento principalmente al codice fiscale).

Per il telefono potrebbe essere utile invece aggiungere un campo con i selettori dei prefissi.

Come da titolo

Come da titolo.

Attualmente, per gestire i form ci sono molte ripetizioni:

• bisogna ripetere <FormError {errorMsg} />
• bisogna ripetere on:blur={handleChange} e error={$errors.username} per ogni field
• e qualcos'altro.

svelte-forms-lib offre già dei componenti che in automatico si aggiornano, in quanto utilizzano la Context API fornita da Svelte, che permette ai componenti di parlarsi senza passarsi esplicitamente tutta una serie di cose – evitando quindi ripetizioni inutili.

Ci sono due soluzioni possibili:

• Temporaneamente, utilizzare i componenti forniti da svelte-forms-lib, personalizzandone al massimo il CSS.
• Sul lungo termine, integrare nella libreria di componenti per i form le logiche della Context API.

Ci possono essere problemi scaturiti dall'utilizzo dei pulsanti "indietro" e "avanti"?

L'obiettivo è inizializzare il client GraphQL una volta sola, in questo modo non si ripete ogni volta la procedura di reinizializzazione.

Reference: timhall/svelte-apollo#97

Se si ritiene opportuno, bisognerebbe reindirizzare l'utente se arriva direttamente, tramite url, a pagine a cui non ha senso arrivare.

Ad esempio:

• Andare alla pagina di conferma iscrizione corso senza che ci si è iscritti.
• Andare a pagine che non hanno contenuto, tipo "logout"

Creare messaggi di errore human-readable per il frontend.
Al momento vengono restituite solo stringhe brevi contenute nell'enum in shared.

Al momento la validazione di un campo viene eseguita on keyup.
Questo significa che appena vengono digitate le prime lettere parte subito la validazione.
Nel caso di un'email, questo è fastidioso perché fino a quando si arriva a digitare '.com' è già partito l'errore.
Si dovrebbe fare in modo che la validazione parta dopo un po' che si è finito di digitare.
Reference: https://schier.co/blog/wait-for-user-to-stop-typing-using-javascript

Allo stesso tempo, quando un campo è invalido e si inizia a cancellare per correggerlo, l'errore dovrebbe sparire.

Il problema è che questa modifica e la precedente vanno parzialmente in conflitto, e bisogna far sì che funzionino insieme.

Quando si crea un corso, il luogo può essere:

• SOS
• Online
• Altro (nome luogo, url luogo, indirizzo completo)

L'indirizzo completo potrebbe essere un componente.

I luoghi potrebbero anche essere entità. Tanto alla fine i due principali saranno SOS e Online, e se poi si svolge un corso da un'altra parte si crea ad hoc l'entità da pannello di controllo.

Potrebbe essere utile mostrare un errore quando il backend è offline?

Cose da fare per migliorare la funzione request:

• In alcuni casi, potrebbe essere che la risposta non sia un JSON. Servirebbe quindi mettere una condizione che gestisce il caso in cui quello che ritorna sia una stringa
• La funzione al momento accetta come body solo oggetti, niente FormData o simili. Si potrebbe quindi generalizzare il comportamento della funzione, tenendo conto che deve girare sia sul server che sul client.

Ci sono problematiche potenziali scaturite dall'avere la pagina di pagamento pubblica?