GettingStarted fr

Premiers pas

🌐 Cette page en : English · Português · Español · Français · Deutsch

Pas envie d'installer quoi que ce soit ? Essayez-le dans le playground, le même compilateur, dans votre navigateur.

Trois commandes, sans Node, sans bundlers, sans JavaScript :

dotnet new install eQuantic.UI.Templates

dotnet new equantic-app -n MonApp

cd MonApp && dotnet run

Ouvrez l'URL affichée : une page thémée, rendue côté serveur, dont le compteur est un composant C# : un champ d'état, un gestionnaire et une méthode Build. Le build l'a compilé en JavaScript pour vous (la chaîne d'outils embarquée fait le bundling ; il n'y a rien à installer).

Ce que le modèle vous donne

MonApp/
├─ MonApp.csproj       # <Project Sdk="eQuantic.UI.Sdk">, cette ligne EST le pipeline de build
├─ global.json         # fige la version du SDK (estampillée par le modèle)
├─ Program.cs          # AddUI → UseTheme → MapUI, UseRequestLocalization pour les cultures
├─ Components/
│  └─ StatTile.cs      # votre premier composant ; sa factory est générée à partir de lui
├─ Pages/
│  └─ HomePage.cs      # [Page("/")], un StatefulComponent write-once
└─ Resources/
   ├─ Strings.resx     # vos chaînes : du resx .NET ordinaire, le seul artefact de localisation
   ├─ Strings.pt-BR.resx
   └─ Strings.Designer.cs

• Les pages sont des classes avec [Page("/route")]. SSR, hydratation, navigation côté client, un vrai 404 pour les routes inconnues (déclarez [Page("/404")] pour le personnaliser), tout est câblé.
• Deux langues dès la naissance. La page d'accueil lit Strings.Tagline dans le resx et affiche un CultureSwitcher : cliquez sur Português et la page se réaffiche sur place, avec Contado {0} vezes. qui se reformate en même temps que le compteur. Ajoutez une troisième langue en créant Strings.fr.resx et en listant fr dans UseRequestLocalization. Voir Localisation pour comprendre comment la même classe répond sur le serveur, dans le navigateur et dans une fenêtre native.
• Écrire un arbre ne demande ni new ni import : Column(gap: Space.S4, children: [ Text("Hi"), Button("Go") ]). Vos propres composants rejoignent cette surface automatiquement, et le StatTile(…) du modèle est le vôtre. Voir Surface déclarative.
• Le thème tient en une ligne : remplacez PhotonTheme.Instance par MaterialTheme.FromSeed(color) dans Program.cs et chaque composant change de marque, serveur et client compris.
• Les données serveur passent par des méthodes [ServerAction], appelées depuis le navigateur comme de simples await C#.
• Hot reload : lancez avec dotnet watch et enregistrez un fichier, le navigateur se met à jour avec votre page, son état conservé.
• Le même code source de composant se réalise NATIVEMENT sur le moteur Photon (shells macOS/iOS/Android). Voir Photon.

Partir d'une forme plutôt que d'une page blanche

Depuis 0.2.0-preview.31

La structure ci-dessus est --shell blank, celle par défaut. Les deux modèles acceptent le paramètre, et chaque forme proposée est ADAPTATIVE, ce qui est tout l'enjeu : ici un facteur de forme n'est pas un second projet, alors le premier écran que voit un nouveau venu a tout intérêt à le dire.

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

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

equantic-app	Ce que vous obtenez
blank	Une page et un compteur.
topnav	Un en-tête avec des liens, et une seconde route qui prouve le routeur.
dashboard	Une barre latérale au-delà de 840dp, les mêmes sections repliées sous l'en-tête en dessous.

equantic-native	Ce que vous obtenez
blank	Un écran et un compteur.
tabs	Des destinations dans une barre basse, qui se redressent en rail de navigation au-delà de 600dp.
drawer	Un panneau coulissant sur téléphone, ancré à côté du contenu au-delà de 840dp.
list-detail	Un volet à la fois sur téléphone, deux côte à côte sur tablette.

Un modèle par facteur de forme renierait la thèse write-once dès le premier fichier qu'ouvre une développeuse, donc c'est un CHOIX de dotnet new sur les deux modèles. La forme vit dans UN seul fichier, AppShell, et rien d'autre ne la nomme : en natif, Program.cs dit UseRoot<AppShell>() quel que soit votre choix ; sur le web un shell est un composant ordinaire que chaque page compose, il a donc une factory générée comme n'importe quel autre et une page écrit AppShell("/", …). Changer de forme plus tard, c'est un fichier, jamais le point d'entrée.

Les moitiés adaptatives ne portent aucun listener : AdaptiveNode détient les deux arbres, le web émet les deux derrière des media queries résolues au build (la bonne est à l'écran au premier affichage, avant que le moindre JavaScript ne tourne) et Photon met en page celle qui tient dans la fenêtre. Comme le web MONTE les deux moitiés, tout ce qui est placé dans les deux tourne deux fois, une instance de composant à deux endroits ; un shell garde donc la page et l'en-tête hors des moitiés et n'adapte que la navigation autour d'eux. La page est alors une seule fois dans l'arbre, au même endroit à toutes les largeurs. Un AppShell généré avec --shell dashboard jusqu'à la 0.2.0-preview.57 mettait la page et l'en-tête dans les deux moitiés, et gagne à passer à cette forme. Voir Composants write-once.

Feeds locaux ou de preview

Tant que les paquets ne sont pas sur nuget.org, pointez un nuget.config vers le feed qui les porte :

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