Conseils Markdown contextualisés

a marqué ce sujet comme résolu.

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 ?

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) :

Stackoverflow
Stackoverflow
Stackoverflow 2
Stackoverflow 2

Qu’en pensez-vous ?

SpaceFox

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.

+0 -0

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, …"

+0 -1

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.

+0 -0

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.

+0 -0

Bon le parsing coté client, c’est faisable.

ache

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.

+0 -0

@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".

+0 -0

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.

Javier

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.

+1 -0

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.

+0 -0

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

Javier

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 :)

+1 -0

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).

+0 -0

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.

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte