GettingStarted de

Erste Schritte

🌐 Diese Seite auf: English · Português · Español · Français · Deutsch

Noch nichts installieren? Probieren Sie es im Playground, derselbe Compiler, in Ihrem Browser.

Drei Befehle, kein Node, keine Bundler, kein JavaScript:

dotnet new install eQuantic.UI.Templates

dotnet new equantic-app -n MeineApp

cd MeineApp && dotnet run

Öffnen Sie die ausgegebene URL: eine getdesignte, serverseitig gerenderte Seite, deren Zähler eine C#-Komponente ist: ein Zustandsfeld, ein Handler und eine Build-Methode. Der Build hat sie für Sie nach JavaScript kompiliert (die eingebettete Toolchain übernimmt das Bundling; es gibt nichts zu installieren).

Was die Vorlage Ihnen mitgibt

MeineApp/
├─ MeineApp.csproj     # <Project Sdk="eQuantic.UI.Sdk">, diese Zeile IST die Build-Pipeline
├─ global.json         # fixiert die SDK-Version (von der Vorlage eingestempelt)
├─ Program.cs          # AddUI → UseTheme → MapUI, UseRequestLocalization für die Kulturen
├─ Components/
│  └─ StatTile.cs      # Ihre erste Komponente; ihre Factory wird aus ihr generiert
├─ Pages/
│  └─ HomePage.cs      # [Page("/")], eine Write-once-StatefulComponent
└─ Resources/
   ├─ Strings.resx     # Ihre Strings: gewöhnliches .NET-resx, das einzige Lokalisierungsartefakt
   ├─ Strings.pt-BR.resx
   └─ Strings.Designer.cs

• Seiten sind Klassen mit [Page("/route")]. SSR, Hydration, clientseitige Navigation und ein echter 404 für unbekannte Routen (mit [Page("/404")] geben Sie ihm Ihre Marke) sind alle verdrahtet.
• Zwei Sprachen von Geburt an. Die Startseite liest Strings.Tagline aus dem resx und rendert einen CultureSwitcher: Klicken Sie auf Português, und die Seite rendert an ihrem Platz neu, wobei Contado {0} vezes. sich zusammen mit dem Zähler umformatiert. Eine dritte Sprache liefern Sie aus, indem Sie Strings.fr.resx anlegen und fr in UseRequestLocalization aufführen. Siehe Lokalisierung dazu, wie dieselbe Klasse auf dem Server, im Browser und in einem nativen Fenster antwortet.
• Einen Baum zu schreiben braucht kein new und keinen Import: Column(gap: Space.S4, children: [ Text("Hi"), Button("Go") ]). Ihre eigenen Komponenten treten dieser Oberfläche automatisch bei, und das StatTile(…) in der Vorlage ist Ihres. Siehe Deklarative Oberfläche.
• Theming ist eine Zeile: Tauschen Sie PhotonTheme.Instance gegen MaterialTheme.FromSeed(color) in Program.cs, und jede Komponente trägt die neue Marke, auf Server und Client.
• Serverdaten laufen über [ServerAction]-Methoden, aus dem Browser als gewöhnliche C#-awaits aufgerufen.
• Hot Reload: Starten Sie mit dotnet watch und speichern Sie eine Datei, und der Browser aktualisiert sich mit Ihrer Seite, ihr Zustand bleibt erhalten.
• Derselbe Komponenten-Quellcode wird NATIV auf der Photon-Engine realisiert (macOS-/iOS-/ Android-Shells). Siehe Photon.

Mit einer Form anfangen statt mit einer leeren Seite

Seit 0.2.0-preview.31

Das Layout oben ist --shell blank, die Voreinstellung. Beide Vorlagen nehmen den Parameter, und jede Form, die sie anbietet, ist ADAPTIV, und genau darum geht es: Ein Formfaktor ist hier kein zweites Projekt, also sollte der erste Bildschirm, den ein Neuankömmling sieht, das auch sagen.

dotnet new equantic-app -n MeineApp --shell dashboard

dotnet new equantic-native -n MeineApp --shell tabs

equantic-app	Was Sie bekommen
blank	Eine Seite und ein Zähler.
topnav	Ein Header mit Links und eine zweite Route, die den Router belegt.
dashboard	Eine Seitenleiste ab 840dp, darunter dieselben Abschnitte unter den Header umgebrochen.

equantic-native	Was Sie bekommen
blank	Ein Bildschirm und ein Zähler.
tabs	Ziele in einer unteren Leiste, die sich ab 600dp zu einer Navigationsschiene aufrichten.
drawer	Ein ausfahrendes Panel auf dem Telefon, ab 840dp neben dem Inhalt angedockt.
list-detail	Auf dem Telefon ein Bereich auf einmal, auf dem Tablet zwei nebeneinander.

Eine Vorlage pro Formfaktor würde die Write-once-These in der ersten Datei verleugnen, die eine Entwicklerin öffnet, also ist dies eine dotnet new-WAHL auf den beiden Vorlagen. Die Form lebt in EINER Datei, AppShell, und nichts sonst benennt sie: Nativ sagt Program.cs UseRoot<AppShell>(), was Sie auch gewählt haben; im Web ist eine Shell eine gewöhnliche Komponente, die jede Seite komponiert, hat also wie jede andere eine generierte Factory, und eine Seite schreibt AppShell("/", …). Die Form später zu tauschen ist eine Datei, nie der Einstiegspunkt.

Die adaptiven Hälften tragen keinen Listener: AdaptiveNode hält beide Bäume, das Web gibt beide hinter Media Queries aus, die zur Build-Zeit entschieden werden (die richtige steht beim ersten Paint auf dem Bildschirm, bevor irgendein JavaScript läuft), und Photon layoutet die, die ins Fenster passt. Weil das Web beide Hälften MOUNTET, läuft alles, was in beiden steht, zweimal, eine Komponenteninstanz an zwei Stellen. Eine Shell hält die Seite und den Header deshalb aus den Hälften heraus und adaptiert nur die Navigation darum herum. Die Seite steht dann einmal im Baum, an derselben Stelle bei jeder Breite. Eine mit --shell dashboard erzeugte AppShell setzte bis 0.2.0-preview.57 Seite und Header in beide Hälften und sollte auf diese Form umgestellt werden. Siehe Write-once-Komponenten.

Lokale und Preview-Feeds

Solange die Pakete nicht auf nuget.org liegen, richten Sie eine nuget.config auf den Feed, der sie trägt:

<configuration>
  <packageSources>
    <add key="equantic" value="PATH-OR-URL-TO-FEED" />
  </packageSources>
</configuration>