Créer une application Web avec Oats~i – Démarrage d'une application Oats~i

Bienvenue dans la deuxième partie de la série de didacticiels Créer une application Web avec Oats~i. Dans la première partie, nous avons procédé à l'installation d'Oats~i dans votre environnement de développement. Au cas où vous l'auriez manqué, consultez-le ici.

Dans cette partie de la série, nous verrons comment démarrer une application Oats~i. Cela couvrira tous les cas où vous souhaitez démarrer une application Oats~i et faire fonctionner le framework sur le front-end.

Au lieu de créer un projet entier à partir de zéro, nous utiliserons le projet de démarrage intégré fourni avec Oats~i lorsque vous le configurerez à l'aide du cli Oats~i. Nous ouvrirons les éléments importants du code nécessaires à ce didacticiel et les utiliserons pour expliquer comment Oats~i se charge lorsqu'il arrive au client/navigateur et commence à exécuter votre application Web.

Plongeons-nous.

Installez le projet de démarrage à l'aide de Oats~i CLI

Créez un nouveau dossier dans lequel vous souhaitez installer le projet de démarrage Oats~i et ouvrez le terminal. Puis exécutez :

npx oats-i-cli

Suivez les instructions.

Cela installera Oats~i et le projet de démarrage qui l'accompagne dans votre répertoire de travail actuel.

Enfin, pour exécuter le projet de démarrage, exécutez

npm run dev

Accédez à l'adresse fournie dans le terminal (souvent localhost : 8080) et voyez le projet de démarrage en action. Naviguez d'avant en arrière entre les pages disponibles pour voir Oats~i gérer le routage et créer des vues à travers des fragments.

Passons maintenant au code qui donne vie à Oats~i dans le client/navigateur.

Index.js

Ouvrez le fichier index.js trouvé dans src -> application -> index -> scripts.

Ce fichier contient le code qui démarre Oats~i pour le projet de démarrage fourni dans le cli. C'est plus ou moins le même code que vous écririez pour démarrer Oats~i dans votre propre projet.

Décomposons-le.

La racine de l'application

Oats~i est généralement initialisé à partir du module appRoot via la méthode appRoot.initApp().

appRoot est une instance singleton de la classe AppRoot qui gère l'initialisation d'une application Web Oats~i, la navigation principale et le chargement de la vue racine si son modèle est fourni.

La méthode initApp() prend plusieurs arguments, notamment une instance de l'objet AppStateManager, MainRouter, AppRootView, une route par défaut et des options supplémentaires facultatives qui vous permettent actuellement de définir le comportement d'interception de lien externe de l'application.

Décomposons-les.

AppStateManager

Le gestionnaire d'état de l'application est un module chargé de gérer les états de route d'une application Oats~i. Principalement, cela aide Oats~i à comprendre si un événement historique est un clic sur le bouton avant ou arrière du navigateur par l'utilisateur.

Cette information n'est pas évidente en utilisant l'API d'historique telle quelle.

Il est crucial de disposer de ces informations car Oats~i enregistre les états des fragments au fur et à mesure que l'utilisateur navigue dans l'application Web. Par conséquent, s’ils doivent revenir en arrière ou en avant vers une page dans laquelle ils se trouvaient auparavant, le(s) fragment(s) responsable(s) du rendu et de l’exécution de ces pages « se souviendront » de leur état, afficheront les bonnes informations et défileront automatiquement vers la bonne position. l'utilisateur était à.

Savoir si l'événement pop est un mouvement vers l'avant ou vers l'arrière rend la récupération des informations d'état précise.

Vous créez simplement une instance d'AppStateManager en appelant new et en transmettant les informations de routage de l'application Web.

Dans notre fichier index.js, nous faisons cela dans la ligne :

const appStateManager = new AppStateManager(AppRoutingInfo);

Nous avons déjà défini notre AppRoutingInfo dans un fichier séparé (nous en reparlerons plus tard).

Routeur principal

Le routeur principal gère le routage dans une application Web Oats~i. Vous créez une instance de routeur en appelant « nouveau », en transmettant les informations de routage de l'application, l'instance de gestionnaire d'état de l'application, un rappel d'erreur, un chemin racine et un rappel de consentement d'itinéraire.

Nous avons déjà parlé des informations de routage de l'application et de l'instance du gestionnaire d'état de l'application, parlons donc des autres arguments que vous transmettez au routeur principal.

Rappel d'erreur

En cas de problème de routage, le routeur principal peut déclencher le rappel d'erreur et vous informer des raisons pour lesquelles le routage a échoué. Tant que vous avez bien défini vos itinéraires, vous ne devriez pas vous soucier de la mise en œuvre de cette méthode, autre que simplement la fournir.

Chemin racine

Le routeur principal vous permet d'appeler directement le routage depuis votre code JavaScript en utilisant la méthode routeTO(). Il détermine également l’itinéraire valide à suivre en fonction des principales informations d’itinéraire de votre application.

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.

Route Consent Callback

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.

AppRootView Object

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”’

Default Route

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.

Extra Options

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.

Complete Code

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.

App Routing Info

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:

• route: this is the route that info is valid for. You cannot repeat a route across your routing infos.
• target: this is the main fragment the route should start building from. Oats~i builds its fragments from the main fragment to the child fragments
• Nested child fragments: these are the child fragments that should also be built for the route, in order. This order typically represents the DOM structure, with the fragment that should be created first in DOM coming before it’s nested child or a child fragment in the same level with it.

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.

App Main Nav Info

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:

• selector: This is a dot selector that Oats~i will use to query the navigation link or button, set up listeners (for buttons only – links/A tags are automatically intercepted), and update its “navigation-state” attribute based on whether its active or not. In your markup, this is simply a class name.
• defaultRoute: this is the default route Oats~i should route to if the navigation button is clicked. For links, since Oats~i automatically intercepts clicks on links/A tags, ensure this matches the value of your href attribute.
• baseActiveRoute: This is the base route for which the navigation button or link should be treated as active. For instance, if you have a navigation button with defaultRoute “/profile” and baseActiveRoute “/profile” and the user navigates to /profile/update-pic, Oats~i will set this button as active since this route starts with the baseActiveRoute value.

Putting Everything Together

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:

• The app routing info
• The app main nav info (for main navigation links in your root view)

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.

Sign Up and Follow for the Next Tutorial

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.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!