 |
Résumé | Cliquer dans la zone de texte de l’éditeur sélectionnera la ligne correspondante dans le volet d’aperçu, et vice versa. |
 |
Lien du dépôt | \u003chttps://github.com/thijsbrilleman/discourse-click-to-edit\u003e |
 |
Guide d’installation | Comment installer des plugins dans Discourse |
Cliquer dans la zone de texte de l’éditeur sélectionnera la ligne correspondante dans le volet d’aperçu, et vice versa.
Très bel ajout à l’édition de base de Discourse. Merci de l’avoir créé.
Cela semble être quelque chose qui devrait être bien accueilli, bien que je n’aie rien à dire à ce sujet.
Bonjour 
Merci, c’est vraiment génial 
Je pense que ce serait formidable d’en faire un composant de thème. 
Cela ne fonctionne pas très bien sur iPad, car il sélectionne tout le texte lors de l’écriture. Cela a l’air très étrange.
Merci, et je suis d’accord. J’y regarderai dès que j’aurai le temps. Vous seriez toujours le bienvenu pour soumettre une pull request.
C’est actuellement le comportement prévu, mais je suis bien sûr ouvert à de meilleures idées. Quel type d’indicateur visuel recommanderiez-vous ?
Il s’afficherait comme du texte collé lorsque quelque chose est réellement sélectionné. Ensuite, il y aurait une action et une réponse.
Curieux, pourquoi s’agit-il d’un plugin plutôt que d’un composant de thème ? Tous ces jetons peuvent être générés côté client, non ?
Excellent travail au passage, j’adore que vous vous appuyiez sur les numéros de ligne injectés par le moteur de rendu markdown.
Merci Sam.
Comme vous l’avez peut-être remarqué, les attributs data-ln sont également présents dans le HTML traité généré et stocké sur le serveur.
J’ai implémenté ce comportement afin de pouvoir étendre ultérieurement le plugin pour permettre l’insertion/modification fiable de fragments à partir de la page de vue du sujet, équivalente au bouton d’édition montré ci-dessous (mais un peu plus robuste) :
Cela fait un an que je l’ai écrit, mais si je me souviens bien, à cette fin, dans plugin.rb, la ligne
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
est nécessaire pour s’assurer que l’extension MarkdownIt s’exécute également côté serveur lors du traitement du HTML.
Je n’ai cependant pas trouvé le temps nécessaire pour implémenter la fonctionnalité d’édition étendue, donc si cette exigence est abandonnée, elle pourrait être convertie en composant, je suppose.
@sam Je suis en train d’essayer de le convertir en un composant de thème, mais je n’arrive pas à comprendre comment exécuter ce code dans le contexte d’un plugin markdownit :
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js :
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers déjà disponible
}
Je soupçonne que la ligne du plugin que j’ai écrite précédemment ajoute également de la magie côté client :
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
Avez-vous une idée ?
Pas sûr, je vais contacter l’équipe.
Je pense que c’est parce qu’il est actuellement limité au champ d’application des plugins uniquement. Cela fonctionnerait sans cette vérification. (Ce code a été introduit dans ce commit)
Je voulais intégrer les numéros de ligne pour un autre composant, mais je ne voulais pas créer de plugin, alors j’ai abandonné. Ce serait super cool si les fonctionnalités markdown pouvaient être prises en charge dans les composants de thème !
Par ailleurs, une excellente fonctionnalité que vous avez proposée ici — très bien. 
Ah oui, cela clarifie les choses.
En regardant ce code, il serait peut-être possible d’injecter manuellement le plugin markdown du composant de thème au moment de l’exécution, mais ce serait assez artisanal. J’attendrai le verdict de l’équipe principale avant d’essayer de l’implémenter.
Notre pipeline markdown s’exécute à la fois sur le client (pour l’aperçu) et sur le serveur (pour le rendu préalable du HTML des publications). C’est pourquoi il est conçu uniquement pour les plugins - ce sont les seuls qui peuvent injecter du code côté serveur.
Maintenant… ce cas est assez inhabituel, car l’extension n’est nécessaire que dans le compositeur, et non sur le serveur. Il devrait donc être possible de le faire à partir d’un composant de thème.
Aviez-vous une stratégie particulière en tête pour cela ?
Cela semble être quelque chose qui aurait un large attrait. Il peut être difficile de trouver sa place dans un long article. Pourrait-il s’agir de pr-welcome ?
Remplacez cette fonction dans le code source d’origine :
// discourse/app/assets/javascripts/discourse/app/components/d-editor.js
async cachedCookAsync(text, options) {
this._cachedCookFunction ||= await generateCookFunction(options || {});
return await this._cachedCookFunction(text);
}
par un composant de thème initialiseur :
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// Dupliquer le code ici pour retourner une fonction de cuisson modifiée
},
});
},
};
Cela impliquerait une quantité considérable de duplication de code, si cela fonctionnait d’une manière ou d’une autre. Sale, sale.
Hmm ouais, d’accord - ce n’est vraiment pas idéal. Dupliquer le code pourrait même ne pas être possible, car les modules markdown-it sont chargés de manière asynchrone et ne font pas partie du système de modules amd auquel les thèmes/plugins ont un accès direct. 
Construire un système pour permettre aux thèmes de contribuer à des transformations md côté client uniquement pourrait être intéressant, bien que les cas d’utilisation soient assez limités. Dans 99% des cas, les gens veulent que les transformations md s’appliquent également côté serveur.
Je pense donc que, pour l’instant, s’en tenir à un plugin est probablement la meilleure approche.
Je me demande si ce genre de décoration devrait être appliqué quoi qu’il arrive ?
Par exemple :
<p data-source-line="0">.....</p>
L’attribut de données supplémentaire aidera bon nombre de nos implémentations internes, comme, par exemple, ne pas afficher l’autocomplétion lorsque vous êtes dans un bloc de code. Le devis et la modification rapide deviennent également beaucoup plus faciles.
L’implémentation triviale n’entraîne presque aucun poids supplémentaire, mais nous permet de supprimer une pile de code source.
Nous avions cela dans le passé (derrière un drapeau), mais cela a été supprimé dans ce commit. J’ai trouvé cette capture d’écran lors de discussions internes sur cette fonctionnalité :
c’est-à-dire que le problème de performance concernait le code de synchronisation du défilement, et non l’injection des numéros de ligne 
Donc oui, je n’ai aucune objection à ajouter l’injection de la ligne data-source dans le cœur, tant qu’elle n’est ajoutée que dans l’aperçu. Est-ce quelque chose que vous seriez intéressé à faire une PR pour @pipkin ?
Volontiers ! Heureux de pouvoir vous rendre quelque chose.
