Bina Apl Web dengan Oats~i – Memulakan Apl Oats~i

Selamat datang ke bahagian kedua siri tutorial Bina Apl Web dengan Oats~i. Pada bahagian pertama, kami telah melalui pemasangan Oats~i dalam persekitaran pembangunan anda. Sekiranya anda terlepas yang itu, semak di sini.

Dalam bahagian siri ini, kami akan membincangkan cara memulakan apl Oats~i. Ini akan merangkumi semua keadaan di mana anda ingin memulakan apl Oats~i dan menjalankan rangka kerja pada bahagian hadapan.

Daripada membina keseluruhan projek dari awal, kami akan menggunakan projek pemula terbina yang disertakan dengan Oats~i apabila anda menyediakannya menggunakan Oats~i cli. Kami akan membuka bit penting kod yang diperlukan untuk tutorial ini dan menggunakannya untuk menerangkan cara Oats~i dimuatkan apabila ia sampai ke klien/penyemak imbas dan mula menjalankan apl web anda.

Jom selami.

Pasang Projek Permulaan Menggunakan Oats~i CLI

Buat folder baharu di mana anda ingin memasang projek permulaan Oats~i dan buka terminal. Kemudian jalankan:

npx oats-i-cli

Ikuti gesaan.

Ini akan memasang Oats~i dan projek pemula yang digabungkan dengannya ke direktori kerja semasa anda.

Akhir sekali, untuk menjalankan projek permulaan, jalankan

npm run dev

Navigasi ke alamat yang disediakan dalam terminal (selalunya localhost:8080) dan lihat projek pemula sedang beraksi. Navigasi ke sana ke mari antara halaman yang tersedia untuk melihat Oats~i mengendalikan penghalaan dan membina pandangan melalui serpihan.

Sekarang mari kita ke kod yang menghidupkan Oats~i dalam klien/pelayar.

Index.js

Buka fail index.js yang terdapat dalam src -> apl -> indeks -> skrip.

Fail ini mengandungi kod yang memulakan Oats~i untuk projek permulaan yang digabungkan dalam cli. Ini adalah lebih kurang sama kod yang anda tulis untuk memulakan Oats~i dalam projek anda sendiri.

Mari kita pecahkan.

Akar Apl

Oat~i biasanya dimulakan daripada modul appRoot melalui kaedah appRoot.initApp().

appRoot ialah contoh tunggal kelas AppRoot yang mengurus permulaan apl web Oats~i, navigasi utama dan memuatkan paparan akar jika templatnya disediakan.

Kaedah initApp() mengambil beberapa hujah, termasuk contoh AppStateManager, MainRouter, AppRootView objek, laluan lalai dan pilihan tambahan pilihan yang pada masa ini membolehkan anda menentukan gelagat pemintasan pautan luaran apl.

Mari kita pecahkan ini.

AppStateManager

Pengurus keadaan apl ialah modul yang bertanggungjawab untuk mengurus keadaan laluan apl Oats~i. Terutamanya, ia membantu Oats~saya memahami sama ada acara pop sejarah ialah satu klik pada butang hadapan atau belakang pada penyemak imbas oleh pengguna.

Maklumat ini tidak jelas menggunakan API sejarah sebagaimana adanya.

Memiliki maklumat ini adalah penting kerana Oats~i menyimpan keadaan serpihan semasa apl web dilayari oleh pengguna. Oleh itu, jika mereka ingin kembali atau maju ke halaman yang mereka berada sebelum ini, serpihan yang bertanggungjawab untuk memaparkan dan menjalankan halaman tersebut akan "mengingat" keadaan mereka dan menunjukkan maklumat yang betul dan secara automatik ditatal ke kedudukan yang betul. pengguna berada di.

Mengetahui sama ada acara pop adalah pergerakan ke hadapan atau belakang menjadikan mendapatkan maklumat keadaan tepat.

Anda hanya membuat contoh AppStateManager dengan menggunakan baharu, menghantar maklumat penghalaan apl web.

Dalam fail index.js kami, kami melakukan ini dalam baris:

const appStateManager = new AppStateManager(AppRoutingInfo);

Kami telah pun menentukan AppRoutingInfo kami dalam fail berasingan (lebih lanjut mengenai perkara ini kemudian).

Penghala Utama

Penghala utama mengendalikan penghalaan dalam apl web Oats~i. Anda membuat tika penghala dengan menggunakan "baharu", menghantar maklumat penghalaan apl, tika pengurus keadaan apl, panggilan balik ralat, laluan akar dan panggilan balik kebenaran laluan.

Kami telah pun bercakap tentang maklumat penghalaan apl dan contoh pengurus keadaan apl, jadi mari kita bincangkan tentang hujah lain yang anda hantar ke penghala utama.

Ralat Panggilan Balik

Sekiranya terdapat masalah penghalaan, penghala utama boleh melancarkan panggilan balik ralat dan memaklumkan anda tentang sebab penghalaan gagal. Selagi anda telah menentukan laluan anda dengan baik, anda tidak perlu risau tentang melaksanakan kaedah ini, selain daripada hanya menyediakannya.

Laluan Akar

Penghala utama membolehkan anda memanggil terus untuk penghalaan daripada kod JavaScript anda menggunakan kaedah routeTO(). Ia juga menentukan laluan yang sah untuk diikuti berdasarkan maklumat penghalaan utama apl anda.

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.

Atas ialah kandungan terperinci Bina Apl Web dengan Oats~i – Memulakan Apl Oats~i. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!