Segnalazione apprezzata @NateDhaliwal
No, si limita a analizzare l’URL alla ricerca di una stringa specifica e precompila il compositore con uno di alcuni modelli quando trova quella stringa.
Il plugin Docus inserisce quella stringa negli URL come una delle sue funzioni, ma questo componente funzionerà con qualsiasi stringa o meccanismo di consegna che qualcuno voglia usare, quindi può essere autonomo. Aggiornerò il readme per spiegarlo.
Ad esempio, potresti dirgli di cercare: /tag/introductions e diventerebbe un componente modello di tag. Oppure potresti usarlo come sto facendo io per inserire quel modello nelle intersezioni di tag, come: tags/intersection/introductions/webdevs
Sposterei la stringa che cerca nella sezione admin in modo che sia più facile per gli altri modificarla e usarla senza dover scavare nel codice.
Onestamente, sto combattendo con un bug da qualche giorno e mi sto strappando (i pochi capelli che mi restano) e probabilmente non avrei dovuto condividerlo così presto. Inserisce sempre un modello quando trova quella stringa nell’URL.
A volte vuoi che si attivi ogni volta che trova quella stringa, a volte vuoi che si attivi solo se non ci sono già altri thread, e a volte vuoi che si attivi solo se quell’utente specifico non ha già creato un thread in quella posizione.
Cosa sta succedendo ora:
L’inizializzatore monitora un tag/stringa nell’URL e apre automaticamente un modello in Discourse ogni volta che rileva una corrispondenza. Questo funziona bene quando voglio sempre aprire un modello, ma crolla quando ho bisogno di condizioni come “non aprire se esiste già un argomento” o “non aprire se questo utente ha già pubblicato”.
Cosa ho tentato:
- Ho introdotto un flag
settings.auto_open_check_user_only. Quando è attivo, il codice cercatags:tag1+tag2 @username; quando è disattivo, cerca solotags:tag1+tag2. L’obiettivo era distinguere tra “esiste qualsiasi argomento” e “esiste l’argomento di questo utente”. - Ho aggiunto un ritardo di 500 ms prima di riattivare il salvataggio della bozza per evitare conflitti con il salvataggio automatico di Discourse.
- Ho iniziato a registrare informazioni di base (ID del trigger, nome del modello) in modo da poter almeno vedere quando si attiva l’apertura automatica.
Sospetto che i problemi siano:
- L’API di ricerca di Discourse restituisce risultati prima che l’indice di ricerca si aggiorni, quindi il sistema continua a pensare che “non esistano argomenti” anche subito dopo che un utente ha pubblicato.
- Il filtraggio per
@usernamenon aiuta se il nome utente non corrisponde esattamente o se i tag non sono allineati con le impostazioni del modello. - Non annullo mai i timer di bozza in sospeso di Discourse, quindi anche se blocco i salvataggi per 500 ms, i salvataggi accodati vengono comunque eseguiti in seguito e riportano la bozza/il compositore.
Sto attualmente provando:
- Dopo aver chiamato
deleteDraft, annullare immediatamente il debounce di_saveDraftdi Discourse in modo che le vecchie bozze non possano riapparire. - Creare una cache di breve durata che ricordi “Ho già creato un argomento qui con questi tag” per coprire il ritardo dell’indice di ricerca.
- Creare 3 modalità selezionabili nella sezione Admin
always (sempre)
Apre il modello ogni volta che i tag corrispondono. Nessuna ricerca, nessun controllo: apri semplicemente il compositore.
ifNoTopics (seNessunArgomento)
Utilizza la ricerca di Discourse per chiedere: Esiste già un argomento con questi tag?
- Se sì → non aprire.
- Se no → apri.
Utile per situazioni in cui dovrebbe esistere un solo argomento.
ifUserHasNoTopic (seUtenteNonHaArgomento)
Cerca: Questo utente specifico ha già creato un argomento con questi tag?
- Se sì → non aprire.
- Se no → apri.
Utile quando a ogni utente dovrebbe essere concesso il proprio thread personale.
Se qualcuno ha suggerimenti su come affronterebbe la creazione di queste impostazioni, mi piacerebbe sentirli.