eQuantic.UIeQuantic.UI
Docs
Playground
GitHub
DocsEmpieza aquí
Primeros pasos
Edit this page
4 min read
¿No quieres instalar nada todavía? Pruébalo en el playground, el mismo compilador, en tu navegador.
Tres comandos, sin Node, sin bundlers, sin JavaScript:
1
dotnet new install eQuantic.UI.Templates
1
dotnet new equantic-app -n MiApp
1
cd MiApp && dotnet run
Abre la URL que aparece: una página con tema y renderizada en el servidor cuyo contador es un componente C#: un campo de estado, un manejador y un método Build. La compilación ya lo convirtió a JavaScript por ti (la cadena de herramientas integrada hace el bundling; no hay nada que instalar).
Lo que te da la plantilla
1
2
3
4
5
6
7
8
9
10
11
12
MiApp/
├─ MiApp.csproj # <Project Sdk="eQuantic.UI.Sdk">, esa línea ES el pipeline de build
├─ global.json # fija la versión del SDK (sellada por la plantilla)
├─ Program.cs # AddUI → UseTheme → MapUI, UseRequestLocalization para las culturas
├─ Components/
│ └─ StatTile.cs # tu primer componente; su factory se genera a partir de él
├─ Pages/
│ └─ HomePage.cs # [Page("/")], un StatefulComponent write-once
└─ Resources/
├─ Strings.resx # tus cadenas: resx .NET corriente, el único artefacto de localización
├─ Strings.pt-BR.resx
└─ Strings.Designer.cs
•
Las páginas son clases con [Page("/ruta")]. SSR, hidratación, navegación en el cliente y un 404 de verdad para rutas desconocidas (declara [Page("/404")] para personalizarlo), todo conectado.
•
Dos idiomas de nacimiento. La página de inicio lee Strings.Tagline del resx y renderiza un CultureSwitcher: pulsa Português y la página se vuelve a renderizar en su sitio, con Contado {0} vezes. reformateándose junto con el contador. Añade un tercer idioma creando Strings.fr.resx y listando fr en UseRequestLocalization. Mira Localización para ver cómo la misma clase responde en el servidor, en el navegador y en una ventana nativa.
•
Escribir un árbol no necesita new ni imports: `Column(gap: Space.S4, children: [ Text("Hi"), Button("Go") ])`. Tus propios componentes se suman a esa superficie automáticamente, y el StatTile(…) de la plantilla es tuyo. Mira Superficie declarativa.
•
El tema es una línea: cambia PhotonTheme.Instance por MaterialTheme.FromSeed(color) en Program.cs y cada componente cambia de marca, en servidor y en cliente.
•
Los datos del servidor pasan por métodos [ServerAction], llamados desde el navegador como awaits de C# corrientes.
•
Hot reload: ejecuta con dotnet watch y guarda un archivo, y el navegador se actualiza con tu página, conservando su estado.
•
El mismo código de componente se realiza de forma NATIVA sobre el motor Photon (shells de macOS/iOS/Android). Mira Photon.
Empezar desde una forma en vez de una página en blanco
Desde 0.2.0-preview.31
La estructura de arriba es --shell blank, la opción por defecto. Las dos plantillas aceptan el parámetro, y cada forma que ofrecen es ADAPTATIVA, que es justo el punto: aquí un factor de forma no es un segundo proyecto, así que más vale que la primera pantalla que ve alguien nuevo lo diga.
1
dotnet new equantic-app -n MiApp --shell dashboard
1
dotnet new equantic-native -n MiApp --shell tabs
equantic-app
Lo que obtienes
blank
Una página y un contador.
topnav
Una cabecera con enlaces, y una segunda ruta que demuestra el router.
dashboard
Una barra lateral a partir de 840dp, las mismas secciones envueltas bajo la cabecera por debajo de ese ancho.
equantic-native
Lo que obtienes
blank
Una pantalla y un contador.
tabs
Destinos en una barra inferior, que se enderezan como raíl de navegación a partir de 600dp.
drawer
Un panel deslizante en el móvil, acoplado junto al contenido a partir de 840dp.
list-detail
Un panel a la vez en el móvil, dos en paralelo en una tableta.
Una plantilla por factor de forma negaría la tesis write-once en el primer archivo que abre quien programa, así que esto es una ELECCIÓN de dotnet new sobre las dos plantillas. La forma vive en UN archivo, AppShell, y nada más la nombra: en nativo, Program.cs dice UseRoot<AppShell>() cualquiera que hayas elegido; en la web un shell es un componente corriente que cada página compone, así que tiene una factory generada como cualquier otro y una página escribe AppShell("/", …). Cambiar la forma más adelante es un archivo, nunca el punto de entrada.
Las mitades adaptativas no llevan ningún listener: AdaptiveNode guarda los dos árboles, la web emite los dos detrás de media queries resueltas en tiempo de build (la correcta está en pantalla en el primer pintado, antes de que corra cualquier JavaScript) y Photon maqueta la que cabe en la ventana. Como la web MONTA las dos mitades, todo lo que se ponga en ambas corre dos veces, una instancia de componente en dos lugares, así que un shell mantiene la página y la cabecera fuera de las mitades y adapta solo la navegación a su alrededor. La página queda entonces una sola vez en el árbol, en el mismo lugar a cualquier ancho. Un AppShell generado con --shell dashboard hasta la 0.2.0-preview.57 ponía la página y la cabecera en las dos mitades, y vale la pena moverlo a esa forma. Mira Componentes write-once.
Feeds locales o de preview
Hasta que los paquetes estén en nuget.org, apunta un nuget.config al feed que los lleva:
1
2
3
4
5
<configuration>
<packageSources>
<add key="equantic" value="PATH-OR-URL-TO-FEED" />
</packageSources>
</configuration>