Von React portieren

Eine bestehende React-Oberfläche zu NoWayOS bringen: mit dem Abdeckungsbericht des Screen Compilers vermessen, sehen, was unverändert umgewandelt wird, was zu ändern ist und was in Ihre Anwendung wandert, und jeden Fehler lesen, den er melden kann.

Sie fangen nicht von vorn an. Das meiste eines React-Screens wird so umgewandelt, wie es geschrieben ist: sein Layout, seine Texte, Buttons und Felder, seine Bedingungen und Listen, seine eigenen kleinen Komponenten. Der Rest ist entweder eine kurze Überarbeitung oder Arbeit, die in Ihre Anwendung wandert, und dort gehört sie auf einem Computer mit einer einzigen Aufgabe auch hin.

Erst vermessen

Bevor Sie eine Zeile ändern, fragen Sie den Screen Compiler, wie weit Ihr Code schon kommt. Klonen Sie Ihre Anwendung neben die beiden Repositorys aus Screens aus React, damit der Dev-Container sie sieht, und lassen Sie den Abdeckungsbericht über ihren Quellcode laufen:

cd nowayos-work # holds nowayos and screen-compiler
git clone https://example.com/your-app.git my-app
cd screen-compiler
make run ARGS="audit ../my-app/src"

Der Bericht liest jede .tsx-Datei unter diesem Ordner und zählt jedes Konstrukt, das er findet: Elemente, Props, Style-Eigenschaften, Hooks, Listen, Bedingungen, Operatoren und Importe. Jedes erhält ein Urteil:

im Subset: es wird umgewandelt, wo es so verwendet wird, wie das Subset es erlaubt;
auf dem Weg: es wird noch nicht umgewandelt, und der Bericht nennt den Schritt, der es umwandeln wird;
bewusst ausgeschlossen: es wird nie umgewandelt, und der Bericht sagt, warum;
unbekannt: der Screen Compiler erkennt es nicht. Unbekanntes zählt nie als umgewandelt.

Danach folgen die Schritte des Wegs mit ihrer Häufigkeit und jede Datei mit ihrem Ergebnis. Eine Datei gilt nur dann als umgewandelt, wenn check sie akzeptiert, die Zahl oben ist also die echte. Der Bericht nennt Konstrukte und zitiert nie Ihren Code, Sie können ihn also bedenkenlos weitergeben. Wie den Compiler selbst lassen Sie ihn nur über Code laufen, dem Sie vertrauen.

Was worauf abgebildet wird

In React DOM	Im Subset
`<div>` mit Flexbox-Layout	`<Column>` oder `<Row>`, mit `gap`, `padding` und einem deklarierten `style`
`<h1>`, `<p>`, `<span>`, `<label>`	`<Text>` in einer Rolle: `title`, `heading`, `body`, `label`, `caption` oder `display`
`<button onClick={…}>`	`<Button onClick={props.onSave}>`: eine Callback-Prop wird zu einer Aktion
`<input>`, eine Checkbox, Radiobuttons, `<select>`	`<TextInput>`, `<Checkbox>`, `<RadioGroup>`, `<Select>`, jeweils mit einer `id`, über die die Anwendung liest und setzt
`{ready && <X/>}`, `? :`, `!ready`, `step === "review"`	Gruppen und Schalter, die die Anwendung setzt
`items.map(…)`	Zeilen: eine Liste aus der Datei oder die Liste einer Prop, auf ein Höchstmaß gekürzt, `props.items.slice(0, 5)`
`Hello, {name}!`	feste Wörter, einkompiliert um einen Slot, den die Anwendung füllt
Eigene Komponenten und Fragmente, in der Datei des Screens oder einer daneben	beim Build aufgelöst, als wäre der Screen flach geschrieben
`style={{ padding: "16px" }}`, `color: "var(--text-muted)"`	die deklarierten Style-Eigenschaften, Längen in Layout-Einheiten, Farben aus dem Theme

Die Tabellen auf Screens aus React listen genau auf, was jede Komponente annimmt. Sie stammen aus den eigenen Tabellen des Screen Compilers und können daher nicht von dem abweichen, was er akzeptiert.

Was in Ihre Anwendung wandert

Auf dem Gerät läuft kein JavaScript. Ein Screen ist ein fester Baum, den Ihre Anwendung über nummerierte Aktionen, Felder, Slots, Gruppen und Schalter steuert. Manches bleibt deshalb bewusst draußen, jeweils aus einem Grund:

State und Hooks (useState, useEffect, Context). Die Anwendung hält den Zustand und setzt, was ein Screen zeigt.
value, checked und onChange eines Felds. Die Anwendung liest und setzt ein Feld über seine id.
Spread-Props. Was sie enthalten, steht erst fest, wenn der Code läuft.
Berechnete Styles, Farbwerte und globale Stylesheets. Ein Style ist statisch, Farben kommen aus dem Theme, damit das Theme mit großer Schrift jeden Screen umfärben kann und der Kontrast geprüft wird, und es gibt keine Kaskade.
Animation.
Eine Liste ohne Höchstmaß. Kürzen Sie sie, .slice(0, 5), damit der Screen weiß, wie viele Zeilen er zeigen darf.
Vergleiche außer einer Prop === einem String, und if oder switch in der Funktion eines Screens. Ermitteln Sie das Ergebnis in der Anwendung und übergeben Sie es als Prop.
Komponenten aus Paketen und aus Dateien außerhalb des Ordners des Screens. Ein Screen liest nur seinen eigenen Ordner und darunter: Legen Sie Ihre Komponenten daneben, ./parts/header.
Ein Handler, der mehr tut, als eine Prop aufzurufen. onClick={() => props.onSave()} wird umgewandelt; alles Weitere ist Arbeit der Anwendung.

Was der Weg als Nächstes bringt

Der Abdeckungsbericht nennt diese geplanten Schritte, wenn Ihr Code sie braucht:

mehr CSS-Layout: Flex-Wachstum, alignSelf, minimale und maximale Höhen, Padding auf jeder Seite und Margins;
gängige HTML-Elemente, jedes nach einer festen Regel;
CSS-Module, eine Klasse pro Element;
Ebenen: Elemente übereinander;
Bilder und maskierte Eingabe.

Bis ein Schritt umgesetzt ist, werden seine Konstrukte abgelehnt statt erraten. Jeder Schritt hält sich an dieselbe Regel: exakt, oder gar nicht.

Einen Fehler lesen

Ein Fehler nennt Datei, Zeile und Spalte, einen Code, was falsch ist, und eine Zeile Hilfe:

web-search.tsx:16:28: error[unknown-name]: `query` is not a prop of the component
 help: text from the application must be a prop: take it as one, function Screen({ query }) { … }

Bei jedem Fehler wird nichts geschrieben. Die Codes:

Code	Was er bedeutet	Was zu tun ist
`syntax`	Die Datei ist kein gültiges TSX oder verletzt eine Regel, die jedes Modul einhält.	Korrigieren Sie den Code an der angegebenen Stelle.
`unsupported`	Ein Konstrukt außerhalb des Subsets.	Folgen Sie der Hilfe: Schreiben Sie es im Subset neu oder verlagern Sie die Arbeit in die Anwendung.
`unknown-element`	Ein Element, das nicht zum Kit gehört oder nicht importiert ist.	Importieren Sie es aus `"nowayos:kit"` oder verwenden Sie das Element des Kits.
`unknown-prop`	Eine Prop oder Style-Eigenschaft, die das Element nicht annimmt.	Verwenden Sie eine, die die Tabellen dafür nennen.
`invalid-value`	Eine Prop, die das Element annimmt, mit einem Wert, den es nicht annimmt.	Geben Sie einen Wert der Art an, die die Tabellen nennen.
`missing-prop`	Eine Prop, die das Element braucht, fehlt.	Geben Sie sie an: Die Tabellen zeigen diese fett.
`invalid-children`	Ein Element enthält, was es nicht enthalten kann, etwa zwei Kinder in `<Screen>` oder Text in einer `<Column>`.	Fassen Sie sie zusammen oder setzen Sie den Text in ein `<Text>`.
`unknown-name`	Ein Name, der weder Prop noch Design-Token noch Import ist.	Nehmen Sie ihn als Prop an oder deklarieren Sie ihn.
`duplicate-name`	Zwei Dinge bekämen im generierten Code denselben Namen, etwa `isReady` und `is_ready`.	Benennen Sie eines um.
`reserved-name`	Ein Name, den Rust oder der generierte Code für sich reserviert, etwa `type`.	Benennen Sie ihn um.
`limit`	Eine Grenze für Größe, Tiefe oder Anzahl ist überschritten.	Kürzen Sie, oder teilen Sie in Komponenten auf.
`no-screen`	Die Datei hat keine Screen-Komponente: eine Funktion, die `<Screen>` zurückgibt.	Exportieren Sie eine.
`internal`	Ein Fehler im Screen Compiler selbst.	Melden Sie ihn, mit der Eingabe, die ihn ausgelöst hat.

Wenn ein Konstrukt, das Sie brauchen, auf dem Weg liegt und noch nicht gebaut ist, sagen Sie es, mit dem Bericht: Er zeigt, welche Schritte am meisten zählen.