Conseils Markdown contextualisés

L’idée serait de donner des conseils sur le Markdown en fonction de ce que tape l’utilisateur, pour qu’ils soient le plus pertinent possible.

Exemples :

• Message long sans saut de ligne ou avec seulement des sauts simples : explication de comment faire des paragraphes
• Que des URL sans code de lien : affichage de la syntaxe du lien
• Image : mention de l’existence de figure
• Balise Maths : affichage des possibilités et contraintes
• Présence d’une URL d’un service vidéo supporté mais non intégrée : affichage du code d’intégration
• etc.

Qu’en pensez-vous ?

Est-ce souhaitable ?

Oui

Est-ce intéressant?

Clairement.

Est-ce pour tout de suite?

Non trop de choses plus importantes à faire avant.

Je ne suis pas trop pour l’aspect d’un texte dynamique/automatique car quand on est concentré sur ce qu’on écrit, je doute qu’on fasse attention au message qui change. Que faire si le "quotient" d’affichage est valide pour l’affichage de plusieurs messages ? Quels messages va-t-on choisir ?

Je verais plus pour un affichage comme StackOverflow (qui s’affiche quand on a besoin) :

Il y a un prérequis : le parsing du markdown côté client.

Ce n’est pas fondamentalement difficile à mettre en place mais ça demande des connaissances en outillage frontend en dehors mes compétences ou centres d’intérêts, du coup je peux pas faire plus que répondre aux questions de la personne qui se proposera pour le faire.

Une fois ce prérequis satisfait, on pourra concevoir un plugin markdown pour détecter des choses et y associer des messages.

Il y a un prérequis : le parsing du markdown côté client.

Obligatoirement ?

Tu peux imaginer un simple appel API avant l’envoi du message au serveur pour publication, ou au "blur" de la zone de texte histoire de demander au serveur ce qu’il en pense.

Je pense pas que y’ait vraiment besoin d’avoir un feedback au fil de la frappe (même, je pense que c’est plus gênant / délicat dans l’implémentation qu’autre chose).

Pour moi un simple feedback lors de l’envoi du message est suffisant, et ça permet d’avoir le parsing et les règles "métier" de feedbacks côté serveur.

Autre point positif de ce mode de fonctionnement : d’autres clients genre ZdSWriter pourraient en bénéficier sans avoir à ré-implémenter de leur côté les règles du type "pas de saut de ligne, pas de figure alternative, …"

Si on part sur un truc serveur, autant le faire à l’aperçu non ?

Bon le parsing coté client, c’est faisable. cepus m’a déjà assisté là-dessus. Mais est-ce vraiment intéressant ? Un parsing toutes les 15, 30, 60 puis 90s vers le serveur, s’il y a des changements est-ce vraiment trop lourd ?
C’est une vrai question hein, je sous entend pas que c’est léger j’essaye de peser le pour et le contre. Car maintenir le parser coté client c’est pas rien non plus même si c’est pas aussi compliqué que ça.

Si on part sur un truc serveur, autant le faire à l’aperçu non ?

Eventuellement, oui.

J’ai proposé cela car cela me paraît également beaucoup plus simple de bénéficier du code existant plutôt que de tout ré-écrire côté client. Et surtout, que si on doit définir l’ensemble des règles dont SpaceFox parle, ça me paraît beaucoup plus sain de dédier un service à cela. Et pas de l’implémenter une fois par client (navigateur, ZestWriter, ou autre). Ca pourrait être un service dédié à la rigueur, pourquoi pas. Mais le faire dans le navigateur me paraît douteux.

Après, atragis a sûrement des arguments contre cela. Ca m’intéresse de les connaître pour le coup.

Je ne suis pas sûr d’avoir compris le rendu de la proposition de Spacefox. Vous voulez faire ça sous forme de conseil qui s’affiche comme l’aide au markown ou d'avertissement bloquant ?

Cette discussion a déjà eu lieu sur ZdS à une époque, et il avait été conclu qu’à cause de possibles disparités entre le rendu côté front et le rendu côté back, l’idée devait être exclue. Le contexte n’a, me semble-t-il, pas changé ; la conclusion non plus.

@Talone le contexte a changé du tout au tout : notre moteur markdown est désormais en JS.

@Javier j’ai mis -1 car tes arguments ne me convainquent pas. Pire, je trouve l’argument des appli externes mauvais car au moins pour zestwritter qui est explicitement cité le but est d’être hors ligne donc forcer un appel serveur pour autre chose quenl’export me semble hors propos.

JE ?

EDIT : surement JS?

Oui je suis sur tablette le correcteur me les brise.

@TAlone: Oui, le contexte à changer

Désormais il est vraiment possible de prendre le parser présent et de l’exporter coté client. Exactement le même sous forme de "bundle web".

C’est pas parce qu’un truc comme webpack minifie du code qu’il faut considérer ça comme tout réécrire. On lui fait manger du code qu’on a déjà écrit, y’a rien à réécrire.

Comme je l’ai dit, le plus simple c’est qu’une fois que zmarkdown tourne côté client pour l’aperçu, on ajoute un petit plugin à zmarkdown qui détecte le non-respect de quelques règles et retourne un message.

Sinon non, au fil de la frappe ça veut pas dire à chaque caractères, c’est pas la bonne approche. Chaque 15s c’est pas la bonne approche non plus. Ce qu’il faut ici c’est du debounce, après pour le délai on verra ce qui est agréable.

Ce qu’il faut ici c’est du debounce, après pour le délai on verra ce qui est agréable

Oui, complètement. Ca c’est de l’UX et c’est typiquement un choix à faire côté client.

Si le fait d’utiliser du code existant, versionné, et indépendant du reste, côté client est déjà prévu, alors ça a du sens d’intégrer cette fonctionnalité à ZMarkdown, via un plugin, en effet.

C’était une information essentielle dont je ne disposais pas. Mea culpa, je me tais.

Mais non, reste, viens plutôt jouer avec : https://github.com/zestedesavoir/zmarkdown/

T’as un peu joué avec des outils front si je me souviens bien, peut-être que tu sauras faire un joli petit web bundle

Ceci dit il me semble que pour assurer la compat avec IE, il faut merger ma PR a propos de startsWith.

T’as un peu joué avec des outils front si je me souviens bien

Ca fait pas partie de mes meilleurs souvenirs. On peut parler de douleur, même.

Ca doit être un peu plus mature maintenant mais…

Y’a une issue ou un truc précis pour cibler les attentes ?

Parce que le projet tel qu’il est, est déjà publiable en tant que module, non ? npm publish ou équivalent ?

Du coup c’est plutôt côté ZdS que ça se passe pour packager tout le front et rajouter la dépendance qui va bien vers ZMarkdown ?

J’imagine que c’est pas le bon endroit pour en parler (d’où la question à propos de l’issue).

Issue ici : https://github.com/zestedesavoir/zmarkdown/issues/259

@artragis : de mon point de vue on s’en fiche un peu de ça, le but c’est que ça fonctionne sur un tas de navigateurs dont IE 11, le but c’est pas de rendre notre code moche.