Xterm.js: Funktionsanfrage: React-Komponente exportieren

Erstellt am 2. Sept. 2016  ·  15Kommentare  ·  Quelle: xtermjs/xterm.js

Wäre wirklich nützlich, wenn xterm.js eine React-Komponente zum einfachen Einbetten in React-Apps exportieren würde. Es könnte nur ein einfacher Wrapper um den vorhandenen Code sein.

typenhancement

Hilfreichster Kommentar

Das ist wirklich ein wirklich interessantes Szenario. Wir versuchen, xterm.js so eigenständig und leicht wie möglich zu halten, da es bereits genug Funktionalität und Komplexität enthält.

Ich denke jedoch, dass das Erstellen eines xtermjs/xterm-react-Repositorys und eines xterm-react-npm-Moduls, das xterm.js einfach in eine React-Komponente einschließen würde, die Aufgabe erfüllen könnte. Wie klingt das?

Alle 15 Kommentare

Das ist wirklich ein wirklich interessantes Szenario. Wir versuchen, xterm.js so eigenständig und leicht wie möglich zu halten, da es bereits genug Funktionalität und Komplexität enthält.

Ich denke jedoch, dass das Erstellen eines xtermjs/xterm-react-Repositorys und eines xterm-react-npm-Moduls, das xterm.js einfach in eine React-Komponente einschließen würde, die Aufgabe erfüllen könnte. Wie klingt das?

Das wäre toll :)

Ich würde wirklich gerne daran arbeiten, aber ich habe ein paar Probleme beim Anpassen des Codes gefunden, ohne ihn zu lückenhaft zu machen. Das Problem besteht darin, dass xtem.js stark von Interaktionen mit dem DOM abhängt, sodass die Trennung der Ansichtslogik äußerst schwierig ist.

Ich möchte eine Funktionsanfrage stellen, um die Logik und die DOM-Behandlung so zu trennen, dass verschiedene Komponenten das Rendern übernehmen können. Ich schlage etwas in der Art des Extrahierens von Terminal.UI aus Terminal vor, das für das Anhängen von Ereignissen an das DOM, das Erstellen und Aktualisieren von Elementen usw. verantwortlich wäre. Terminal würde darauf warten, dass Terminal.UI Ereignisse wie Tastendruck und Scrollen auslöst Auf diese Weise wäre es vollständig vom Rendern entkoppelt. Ich denke, Sie haben mit dem Viewport begonnen, in diese Richtung zu gehen, aber ich glaube, eine vollständige Trennung ist angebracht.

Ich würde gerne Ihre Meinung dazu hören, und ich würde gerne dabei helfen, falls Sie denken, dass es relevant ist.

Ich glaube, dass angesichts der Komplexität des Codes in diesem Projekt eine gewisse Trennung der Anliegen bei der zukünftigen Entwicklung und Wartung wirklich hilfreich sein könnte, und ich bin ein großer Fan des Prinzips der Einzelverantwortung :smile:

@iMoses Wir haben langsam versucht, den Code zu modularisieren, die Möglichkeit, Module aus der Hauptdatei zu verschieben, wurde gerade erst hinzugefügt. Hier ist ein verwandtes Problem, das ebenfalls diese Trennung erfordert: https://github.com/sourcelair/xterm.js/issues/266

Beginnend mit dem Ansichtsfenster, um die verschiedenen überschaubaren Sounds gut zu halten 👍

Fortsetzung der Diskussion von # 285, da es meiner Meinung nach besser geeignet ist.

@iMoses können Sie sagen, welche Methoden des Kernmoduls es Ihnen erschweren, die Reaktionskomponente zu implementieren?

Vielleicht wäre es das Beste, nur diese in eigene Module zu verzweigen.

Nicht alles in dieser Liste ist schwierig zu bearbeiten, wenn ich beispielsweise die open -Methode nicht verwende, werden andere problematische Methoden nicht ausgelöst, aber ich glaube immer noch, dass sie in ein anderes Modul getrennt werden sollten. Das meiste, was ich hier aufliste, kann in meiner Pull-Anfrage in der Datei Interface.js gefunden werden.

Alles in Viewport und CompositionHelper, aber das ist offensichtlich :)

Aus der xterm.js-Datei sind dies die Hauptmethoden, die getrennt werden sollten:
Blur, Focus, Bind*, InitGlobal, PrepareCopiedTextForClipboard, InsertRow, Open, LoadAddon, Destroy, Refresh, AttachCustomKeydownHandler, KeyDown, EvaluationKeyEscapeSequence, KeyPress, Bell, Cancel.

„bell“ und „application-mode“ sollten Ereignisse auslösen, anstatt mit der UI-Logik zu interagieren.

Ich glaube, das ist das meiste, aber wir müssen auf die Verwendung von UI-Elementen im Code achten (z. B. this.viewport und this.element sollten niemals direkt vom Kernmodul verwendet werden.

Ich hoffe das hilft.

PS
Wie gesagt, ich arbeite derzeit an einem Reach XTerm.js-Beispiel, für das ich die xterm-Bibliothek auf das Nötigste reduziert habe. Ich hoffe, ich werde in weniger als einer Woche fertig sein, und dann werde ich meinen Code mit Ihnen teilen, damit Sie ihn überprüfen können.
Es funktioniert derzeit hervorragend auf meinem Computer, mit den folgenden Ausnahmen: Ich habe noch keine Mausereignisse angehängt, ich habe ein kleines Rendering-Problem, das ich beheben muss, indem ich Teile von refresh umschreibe, während dies der Fall ist Ich möchte, dass React die Rendering-Logik und nicht die Bibliothek verarbeitet.

Hoffe das hilft

Es könnte gut sein, sich https://github.com/sourcelair/xterm.js/issues/266 anzusehen, bevor Sie versuchen, dies anzugehen

Wenn wir zwischen der Kernlogik und der UI-Logik trennen, kann der Kern initialisiert werden, ohne sich um den Dom zu kümmern, und nur bei Bedarf kann die Ansicht initialisiert werden, wobei ihr eine Terminal-Kerninstanz zum Arbeiten übergeben wird.

Ich versuche, die Mausereignisse zu testen, um festzustellen, dass ich nichts kaputt gemacht habe, und ich kann keine Terminalanwendung mit vollständiger Mausunterstützung finden, die beispielsweise Mausbewegungen enthält. Womit testet ihr diese Bibliothek, um sicherzustellen, dass Mausereignisse ordnungsgemäß funktionieren?

Ich habe tatsächlich ein npm-Paket für eine React-Xterm-Komponente erstellt.
Sie können von dort aus beginnen.
Auf Wunsch kann ich sogar das Github-Quellprojekt übertragen
https://github.com/farfromrefug/react-xterm

Danke @farfromrefug! Es wäre toll, wenn wir nicht mit „tabula rasa“ anfangen würden.

Dies ist etwas, das meiner Meinung nach besser von der Community erledigt werden sollte. Ich schließe, um die Anzahl unserer Probleme zu reduzieren, aber ich ermutige jemanden, dies zusammenzustellen.

Ich hoffe, Sie haben nichts dagegen, dass ich ein geschlossenes Problem kommentiere, aber ich habe an einem benutzerdefinierten React-Renderer gearbeitet, um mit xtermjs zu arbeiten. Es bietet eine Reihe von Elementen (z. B. <text> , <line> , <br> ), die zum Schreiben in die Terminalausgabe verwendet werden können. Um es zu verwenden, exportiert das Paket eine render(element, HTMLElement) -Methode, die ein Terminal zu einem bereitgestellten DOM-Element rendert. Es funktioniert auch mit bestehenden React-DOM-Projekten, indem es eine <Terminal> -Komponente bereitstellt, die in jeder vorhandenen render $-Komponentenmethode abgelegt werden kann. Ich bin mir nicht sicher, ob Sie irgendetwas mit diesem Projekt machen möchten, aber ich dachte nur, ich würde es hier hervorheben, falls jemand immer noch eine Reaktionsintegration wünscht:
https://github.com/alex-saunders/xterm-react-renderer

(immer noch ein WIP, aber es funktioniert im Moment als Proof of Concept)

@alex-saunders danke für den Aufruf, gut, einen Link in dieser Ausgabe zu haben, falls die Leute danach suchen 👌

Hallo. Ich konnte eine Reaktionskomponente fast ohne Code und mit dem "neuen" Hook-System einrichten. Es ist jedoch für die Verwendung in Elektronenszenarien ziemlich eng mit node-pty gekoppelt. Ich kann im Moment keinen Code teilen, da es sich um ein geschlossenes, internes Projekt handelt, aber ich ermutige jeden, das Problem mit einer Hook-basierten Lösung neu anzugehen - es lohnt sich!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Tyriar picture Tyriar  ·  4Kommentare

chris-tse picture chris-tse  ·  4Kommentare

fabiospampinato picture fabiospampinato  ·  4Kommentare

Tyriar picture Tyriar  ·  4Kommentare

Mlocik97-issues picture Mlocik97-issues  ·  3Kommentare