Xterm.js: Demande de fonctionnalité : exporter le composant React

Créé le 2 sept. 2016  ·  15Commentaires  ·  Source: xtermjs/xterm.js

Ce serait vraiment utile si xterm.js exportait un composant React pour une intégration facile dans les applications React. Il pourrait s'agir d'un simple wrapper autour du code existant.

typenhancement

Commentaire le plus utile

C'est vraiment un scénario très intéressant. Nous essayons de garder xterm.js aussi autonome et léger que possible, car il contient déjà suffisamment de fonctionnalités et de complexité.

Je pense cependant que la création d'un référentiel xtermjs/xterm-react et d'un chapeau de module npm xterm-react envelopperait simplement xterm.js dans un composant React pourrait faire l'affaire. Comment ça sonne?

Tous les 15 commentaires

C'est vraiment un scénario très intéressant. Nous essayons de garder xterm.js aussi autonome et léger que possible, car il contient déjà suffisamment de fonctionnalités et de complexité.

Je pense cependant que la création d'un référentiel xtermjs/xterm-react et d'un chapeau de module npm xterm-react envelopperait simplement xterm.js dans un composant React pourrait faire l'affaire. Comment ça sonne?

Ce serait génial :)

J'aimerais vraiment travailler là-dessus, mais j'ai trouvé quelques problèmes avec l'ajustement du code sans le rendre trop inégal. Le problème est que xtem.js relaie fortement les interactions avec le DOM, il est donc extrêmement difficile de séparer la logique de la vue.

J'aimerais faire une demande de fonctionnalité pour séparer la logique et la gestion DOM d'une manière qui permettra à différents composants de prendre en charge le rendu. Je suggère quelque chose dans les lignes d'extraction de Terminal.UI à partir de Terminal, qui serait chargé d'attacher des événements au DOM, de créer et de mettre à jour des éléments, etc. Terminal attendrait que Terminal.UI déclenche des événements, tels que la pression sur les touches et le défilement, qui façon dont il serait complètement découplé du rendu. Je pense que vous avez commencé à aller dans cette direction avec le Viewport, mais je pense qu'une séparation complète est de mise.

J'aimerais entendre vos réflexions à ce sujet, et j'aimerais vous aider si vous pensez que c'est pertinent.

Je crois que pour la complexité du code dans ce projet, une certaine séparation des préoccupations pourrait vraiment aider dans le développement et la maintenance futurs, et je suis un grand fan du principe de responsabilité unique :sourire:

@iMoses, nous avons lentement essayé de modulariser le code, la possibilité de déplacer des modules hors du fichier principal vient juste d'être ajoutée. Voici un problème connexe qui appelle également à cette séparation : https://github.com/sourcelair/xterm.js/issues/266

En commençant par la fenêtre pour garder les différents sons gérables bons 👍

Poursuite de la discussion du #285 car c'est plus adapté je pense.

@iMoses pouvez-vous dire quelles méthodes du module principal vous empêchent d'implémenter le composant de réaction ?

Peut-être que la meilleure chose serait de les ramifier uniquement dans leurs propres modules.

Tout dans cette liste n'est pas difficile à travailler, par exemple si je n'utilise pas la méthode open alors une autre méthode problématique ne sera pas déclenchée, mais je pense toujours qu'elles devraient être séparées dans un module différent. La plupart de ce que je vais énumérer ici se trouve dans ma pull-request dans le fichier Interface.js.

N'importe quoi dans Viewport et CompositionHelper, mais c'est évident :)

A partir du fichier xterm.js, voici les principales méthodes qui doivent être séparées :
blur, focus, bind*, initGlobal, prepareCopiedTextForClipboard, insertRow, open, loadAddon, destroy, refresh, attachCustomKeydownHandler, keyDown, assessKeyEscapeSequence, keyPress, bell, cancel.

'bell' et 'application-mode' devraient déclencher des événements au lieu d'interagir avec la logique de l'interface utilisateur.

Je pense que c'est la plupart du temps, mais nous devons faire attention aux utilisations de l'élément d'interface utilisateur dans le code (par exemple, this.viewport et this.element ne doivent jamais être utilisés directement par le module principal.

J'espère que cette aide.

PS
Comme je l'ai dit, je travaille actuellement sur un exemple Reach XTerm.js, pour lequel j'ai réduit la bibliothèque xterm à l'essentiel dont j'ai besoin. J'aurai terminé dans moins d'une semaine, j'espère, puis je partagerai mon code avec vous pour que vous le révisiez.
Cela fonctionne actuellement très bien sur ma machine, avec les exceptions suivantes : je n'ai pas encore attaché d'événements de souris, j'ai un problème de rendu mineur que je devrai résoudre en réécrivant des parties de refresh du fait que Je veux que React gère la logique de rendu et non la bibliothèque.

J'espère que cela t'aides

Il serait peut-être bon de consulter https://github.com/sourcelair/xterm.js/issues/266 avant d'essayer de résoudre ce problème

Si nous séparons entre la logique de base et la logique de l'interface utilisateur, le noyau peut être initialisé sans se soucier du dom et seulement lorsque cela est nécessaire, la vue peut être initialisée, en lui passant une instance de noyau de terminal avec laquelle travailler.

J'essaie de tester les événements de la souris pour voir que je n'ai rien cassé, et je ne trouve pas d'application de terminal avec prise en charge complète de la souris avec déplacement de la souris, par exemple. Sur quoi testez-vous cette bibliothèque pour vérifier que les événements de souris fonctionnent correctement ?

J'ai en fait créé un package npm pour un composant react-xterm.
Vous pouvez commencer à partir de là.
Je peux même transférer le projet source github si je le souhaite
https://github.com/farfromrefug/react-xterm

Merci @farfromrefug ! Ce serait bien si nous ne commencions pas par "tabula rasa".

C'est quelque chose qui serait mieux fait par la communauté imo, je ferme pour réduire notre nombre de problèmes mais j'encourage quelqu'un à mettre cela ensemble.

J'espère que cela ne vous dérange pas que je commente un problème clos, mais j'ai travaillé sur un moteur de rendu React personnalisé pour travailler avec xtermjs. Il fournit un certain nombre d'éléments (tels que <text> , <line> , <br> ) qui peuvent être utilisés pour écrire sur la sortie du terminal. Pour l'utiliser, le package exporte une méthode render(element, HTMLElement) qui affiche un terminal dans un élément DOM fourni. Il fonctionne également avec les projets React-DOM existants en fournissant un composant <Terminal> qui peut être déposé dans n'importe quelle méthode render composants existants. Je ne sais pas si vous voulez faire quoi que ce soit avec ce projet, mais j'ai juste pensé que je le mettrais en évidence ici au cas où quelqu'un voudrait toujours une intégration de réaction :
https://github.com/alex-saunders/xterm-react-renderer

(toujours un WIP mais cela fonctionne comme une preuve de concept pour le moment)

@alex-saunders merci de l'avoir appelé, c'est bien d'avoir un lien dans ce numéro au cas où les gens chercheraient 👌

Salut. J'ai pu mettre en place un composant de réaction avec presque aucun code et en utilisant le "nouveau" système de crochets. Cependant, il est plutôt étroitement couplé à node-pty pour une utilisation dans des scénarios d'électrons. Je ne peux pas partager de code pour le moment, car il s'agit d'un projet interne fermé, mais j'encourage tout le monde à essayer de résoudre le problème à l'aide d'une solution basée sur le hook - ça vaut le coup !

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

7PH picture 7PH  ·  4Commentaires

circuitry2 picture circuitry2  ·  4Commentaires

jestapinski picture jestapinski  ·  3Commentaires

Tyriar picture Tyriar  ·  4Commentaires

albinekb picture albinekb  ·  4Commentaires