Willkommen zum zweiten Teil der Tutorialreihe „Build a Web App with Oats~i“. Im ersten Teil haben wir Oats~i in Ihrer Entwicklungsumgebung installiert. Falls Sie das verpasst haben, schauen Sie es sich hier an.
In diesem Teil der Serie erfahren Sie, wie Sie eine Oats~i-App starten. Dies deckt alle Fälle ab, in denen Sie eine Oats~i-App starten und das Framework im Frontend ausführen möchten.
Anstatt ein ganzes Projekt von Grund auf neu zu erstellen, verwenden wir das integrierte Starterprojekt, das mit Oats~i geliefert wird, wenn Sie es mit der Oats~i-CLI einrichten. Wir öffnen die wichtigen Teile des für dieses Tutorial erforderlichen Codes und erklären anhand dieser, wie Oats~i geladen wird, wenn es den Client/Browser erreicht und mit der Ausführung Ihrer Web-App beginnt.
Lass uns eintauchen.
Erstellen Sie einen neuen Ordner, in dem Sie das Oats~i-Starterprojekt installieren möchten, und öffnen Sie das Terminal. Führen Sie dann Folgendes aus:
npx oats-i-cli
Folgen Sie den Anweisungen.
Dadurch werden Oats~i und das damit gebündelte Starterprojekt in Ihrem aktuellen Arbeitsverzeichnis installiert.
Um schließlich das Starterprojekt auszuführen, führen Sie
aus
npm run dev
Navigieren Sie zu der im Terminal angegebenen Adresse (häufig localhost:8080) und sehen Sie sich das Starterprojekt in Aktion an. Navigieren Sie zwischen den verfügbaren Seiten hin und her, um zu sehen, wie Oats~i das Routing übernimmt und Ansichten durch Fragmente erstellt.
Jetzt kommen wir zum Code, der Oats~i im Client/Browser zum Leben erweckt.
Öffnen Sie die Datei index.js in src -> App -> Index -> Skripte.
Diese Datei enthält den Code, der Oats~i für das in der CLI gebündelte Starterprojekt startet. Dies ist mehr oder weniger derselbe Code, den Sie schreiben würden, um Oats~i in Ihrem eigenen Projekt zu starten.
Lassen Sie es uns aufschlüsseln.
Oats~i wird normalerweise vom appRoot-Modul über die Methode appRoot.initApp() initialisiert.
appRoot ist eine Singleton-Instanz der AppRoot-Klasse, die die Initialisierung einer Oats~i-Web-App, die Hauptnavigation und das Laden der Root-Ansicht verwaltet, sofern ihre Vorlage bereitgestellt wird.
Die initApp()-Methode benötigt mehrere Argumente, darunter eine Instanz des AppStateManager-, MainRouter- und AppRootView-Objekts, eine Standardroute und optionale Zusatzoptionen, mit denen Sie derzeit das Abfangverhalten externer Links der App definieren können.
Lassen Sie uns diese aufschlüsseln.
Der App State Manager ist ein Modul, das für die Verwaltung der Routenzustände einer Oats~i-App verantwortlich ist. In erster Linie hilft es Oats~i zu verstehen, ob ein History-Pop-Ereignis ein Klick des Benutzers auf die Vor- oder Zurück-Schaltfläche im Browser ist.
Diese Informationen sind mit der Verlaufs-API in ihrer jetzigen Form nicht offensichtlich.
Das Vorhandensein dieser Informationen ist von entscheidender Bedeutung, da Oats~i Fragmentzustände speichert, während der Benutzer durch die Web-App navigiert. Wenn sie also zu einer Seite, auf der sie sich zuvor befanden, zurück- oder vorwärts gehen, „merken“ sich die Fragmente, die für die Darstellung und Ausführung dieser Seiten verantwortlich sind, ihren Status, zeigen die richtigen Informationen an und werden automatisch an die richtige Position gescrollt Benutzer war bei.
Wenn Sie wissen, ob es sich bei dem Pop-Ereignis um eine Vorwärts- oder Rückwärtsbewegung handelt, können Zustandsinformationen genau abgerufen werden.
Sie erstellen einfach eine Instanz des AppStateManager, indem Sie new aufrufen und die Routing-Informationen der Web-App übergeben.
In unserer index.js-Datei tun wir dies in der Zeile:
const appStateManager = new AppStateManager(AppRoutingInfo);
Wir haben unsere AppRoutingInfo bereits in einer separaten Datei definiert (mehr dazu später).
Der Hauptrouter übernimmt das Routing in einer Oats~i-Web-App. Sie erstellen eine Router-Instanz, indem Sie „neu“ aufrufen und die Routing-Informationen der App, die App-Status-Manager-Instanz, einen Fehlerrückruf, einen Root-Pfad und einen Routenzustimmungsrückruf übergeben.
Wir haben bereits über die App-Routing-Informationen und die App-State-Manager-Instanz gesprochen, also sprechen wir über die anderen Argumente, die Sie an den Hauptrouter übergeben.
Im Falle eines Problems beim Routing kann der Hauptrouter den Fehlerrückruf auslösen und Sie über die Gründe informieren, warum das Routing fehlgeschlagen ist. Solange Sie Ihre Routen gut definiert haben, sollten Sie sich über die Implementierung dieser Methode keine Gedanken machen, außer sie lediglich bereitzustellen.
Mit dem Hauptrouter können Sie das Routing mithilfe der Methode routeTO() direkt aus Ihrem JavaScript-Code heraus aufrufen. Außerdem wird anhand der Hauptrouteninformationen Ihrer App die gültige zu befolgende Route ermittelt.
Now, if you have Oats~i running in your website with a special address such as /admin, it can be repetitive having to start every routing call or routing info with the /admin root. Instead, you can supply this to the main router as the root path, and just append the rest of your route to your routing calls or routing info.
So, instead of /admin/create, with the root path set to /admin, you can just have the route as /create. However, href attributes in links MUST be fully qualified.
Before the main router can trigger routing for a given path, it attempts to see whether routing for that route has been permitted. The route consent callback allows you to specify this, giving you the ability to control which sections of your web app can be accessed by a given user or based on any other business or app logic.
Note: This is different from fragment consenting, which we’ll cover later.
The app root view object consists of the root view template and array of main navigation infos.
Every Oats~i app has a root view. This is the permanent section of the view which the user will always see regardless of the path they’re navigating to. The root view is wrapped within an tag and will typically contain elements such as your navbar and footer.
Here’s an example, sourced from home.sv.hbs in the Oats~i starter project
<app-root id="my-app">
<div id="nav">
<a href="/" class="nav-link open-sans-txt home-link"><span></span><span>Home</span></a>
<a href="/about" class="nav-link open-sans-txt about-link"><span></span><span>About</span></a>
</div>
<div id="site-bg"></div>
<main-fragment>
</main-fragment>
</app-root>
Note: As you can infer from the Oats~i starter project, you can skip passing in a template for the app root view in the initApp() method as long as you’ve provided it in the html markup sourced for your page from the server.
Your root view object should also have a single tag specified within, where the app’s fragments will be loaded.
The AppRootView object also takes a main navigation info array, which contains a list of selectors and their active routes, which Oats~i will use to show you which navigation selector is active.
In the Oats~i starter project, specifying the main nav info makes it possible to update the styling and looks of the navigation links when you click on it and navigate to its url.
Oats~i handles the click and update boiler plate for the navigation links or buttons. All you have to do is style the links or buttons based on which one is marked as active using the attribute ‘navigation-state=”active”’
The default route is the route Oats~i will default to incase the page loads from a url that is not specified in your app’s routing info. You can use this to curate the default web app behavior especially if it results from a log in or authentication action.
For instance, if the user has come in from a login page and is redirected to their admin page, but the initial page load is at “/admin”, you can specify the default route to be “/admin/dashboard”.
Oats~i will reroute the web app to /admin/dashboard on load and the user will always access their dashboard every time they come from logging into the app.
If you want to change this behavior to say, profile, you can simply change the default route in your web app to /admin/profile and all users logging in will have their profile page as the default page.
Oats~i also takes in optional extra options, with the current implementation allowing you to intercept external links within your web app. This allows you to warn users of their navigation away from your site and the url they’re about to access, in case you want to build a content protection system.
The complete code for starting an Oats~i app will look something like this:
//sourced from index.js in the starter app
const appStateManager = new AppStateManager(AppRoutingInfo);
appRoot.initApp(appStateManager, new MainRouter(AppRoutingInfo, appStateManager, (args) => {}, "", async (url) => {
return {
canAccess: true,
fallbackRoute: "/"
}
}), { template: null, mainNavInfos: AppMainNavInfo }, "");
You can wrap this code within a function that is automatically invoked when your index.js file downloads in the browser to have the web app automatically started on page load. In the starter project’s case, this is the initApp() function.
Now, there are two more things left to explain.
From the startup code, you can point out that providing routing information is mandatory for an Oats~i web app to initialize. From the example’s I’ve given, we define this info elsewhere then import it in our startup script. Defining your routing info in a separate file is not mandatory, but I find it to be good practice especially when you want to add more routes or main navigation in your web app.
Here’s how routing information is defined for an Oats~i web app, using the example from the starter project.
const AppRoutingInfo = RoutingInfoUtils.buildMainRoutingInfo([
{
route: "/",
target: homeMainFragmentBuilder,
nestedChildFragments: null
},
{
route: "/about",
target: aboutMainFragmentBuilder,
nestedChildFragments: null
}
], AppMainNavInfo);
You can call the routing info any name you want, as long as you use the method RoutingInfoUtils.buildMainRoutingInfo() to build it.
The method will return an array of routing information, with each info holding:
You can notice that we also pass AppMainNavInfo to the buildMainRoutingInfo() method as well. This is the same info we passed in to the app state manager and initApp method in the starter script. Let’s look at it.
A good web app needs good navigation. And often, setting up navigation can involve a lot of boiler plate code to not only set up the click listeners for the navigation links or buttons, but also change their styling based on which one is active.
Oats~i takes care of the boiler plate for you by requiring you only provide the navigation information needed by your web app. This takes the following format (example sourced from the starter project).
const AppMainNavInfo = MainNavigationInfoBuilder.buildMainNavigationInfo([
{
selector: "home-link",
defaultRoute: "/",
baseActiveRoute: "/",
},
{
selector: "about-link",
defaultRoute: "/about",
baseActiveRoute: "/about",
}
]);
You create a main navigation info in Oats~i using the method MainNavigationInfoBuilder.buildMainNavigationInfo(). It returns an array of navigation infos, with each containing:
Let’s put everything together and have the final picture of what you need to get an Oats~i app up and running. Typically, you must have defined:
Then, simply get a new instance of the app state manager, and call appRoot.initApp passing this instance, the app routing info, app main nav info, and main router instance. Again, here’s the example code from the Oats~i starter project that comes bundled with the cli, now wrapped in a function that we call immediately the index.js file loads in the browser.
function initApp(){
const appStateManager = new AppStateManager(AppRoutingInfo);
appRoot.initApp(appStateManager, new MainRouter(AppRoutingInfo, appStateManager, (args) => {}, "", async (url) => {
return {
canAccess: true,
fallbackRoute: "/"
}
}), { template: null, mainNavInfos: AppMainNavInfo }, "");
}
initApp();
As your web app grows and changes, the only bits of this code you’ll ever need to change are the app routing infos and main navigation infos (AppRoutingInfo and AppMainNavInfo). This will be typically because you’re adding new routes to your web app (thus updating the routing information) or adding new main navigation buttons or links (thus updating the main navigation infos).
The rest of the code will be fine untouched.
A lot of this will make sense when we build our very own small project in Oats~i. That’s what we’ll be doing in the next part of this series, to learn the next fundamental concepts around building an Oats~i web app.
See you then.
Support Oats~i
You can support the development of Oats~i through Patreon or buy me a coffee.
Das obige ist der detaillierte Inhalt vonErstellen Sie eine Web-App mit Oats~i – Starten einer Oats~i-App. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
