歡迎來到使用 Oats~i 教學系列建立 Web 應用程式的第二部分。在第一部分中，我們在您的開發環境中安裝了 Oats~i。如果您錯過了這一點，請在這裡查看。
在本系列的這一部分中，我們將介紹如何啟動 Oats~i 應用程式。這將涵蓋您想要啟動 Oats~i 應用程式並讓框架在前端運行的所有實例。
當您使用 Oats~i cli 設定它時，我們將使用 Oats~i 附帶的內建啟動項目，而不是從頭開始建立整個專案。我們將打開本教學所需的重要程式碼部分，並用它來解釋 Oats~i 在到達客戶端/瀏覽器並開始運行您的網頁應用程式時如何載入。
讓我們開始吧。
建立一個要安裝 Oats~i 入門專案的新資料夾並開啟終端。然後運行：
npx oats-i-cli
按照提示操作。
這會將 Oats~i 以及與其捆綁的入門項目安裝到您目前的工作目錄。
最後，要執行啟動項目，請執行
npm run dev
導覽至終端機中提供的位址（通常是 localhost:8080）並查看正在執行的啟動項目。在可用頁面之間來回導航以查看 Oats~i 處理路由並透過片段建立視圖。
現在讓我們來看看在客戶端/瀏覽器中使 Oats~i 栩栩如生的程式碼。
開啟src中找到的index.js檔->應用程式->索引->腳本。
此檔案包含為 cli 中捆綁的入門專案啟動 Oats~i 的程式碼。這或多或少與您在自己的專案中啟動 Oats~i 時編寫的程式碼相同。
讓我們來分解一下。
Oats~i 通常是透過 appRoot.initApp() 方法從 appRoot 模組初始化的。
appRoot 是 AppRoot 類別的單例實例，用於管理 Oats~i Web 應用程式的初始化、主導航以及載入根視圖（如果提供了模板）。
initApp() 方法採用多個參數，包括 AppStateManager、MainRouter、AppRootView 物件的實例、預設路由以及目前允許您定義應用程式的外部連結攔截行為的可選額外選項。
讓我們來分解一下。
應用程式狀態管理器是負責管理 Oats~i 應用程式的路由狀態的模組。主要是幫助Oats~我了解歷史彈出事件是否是用戶點擊瀏覽器上的前進或後退按鈕。
原樣使用歷史 API，此資訊並不明顯。
擁有此資訊至關重要，因為 Oats~i 會在使用者導航 Web 應用程式時保存片段狀態。因此，如果他們要返回或前進到之前所在的頁面，負責渲染和運行這些頁面的片段將「記住」它們的狀態並顯示正確的訊息，並自動滾動到正確的位置。用戶位於。
了解彈出事件是向前還是向後移動可以使檢索狀態資訊更加準確。
您只需呼叫 new 並傳入 Web 應用程式的路由資訊即可建立 AppStateManager 的實例。
在我們的index.js 檔案中，我們在以下行中執行此操作：
const appStateManager = new AppStateManager(AppRoutingInfo);
我們已經在一個單獨的檔案中定義了 AppRoutingInfo（稍後會詳細介紹）。
主路由器處理 Oats~i Web 應用程式中的路由。您可以透過呼叫「new」來建立一個路由器實例，傳入應用程式的路由資訊、應用程式狀態管理器實例、錯誤回呼、根路徑和路由同意回呼。
我們已經討論了應用程式路由資訊和應用程式狀態管理器實例，所以讓我們討論一下傳遞給主路由器的其他參數。
如果路由出現問題，主路由器可以觸發錯誤回呼並通知您路由失敗的原因。只要你定義好了你的路由，你就不用擔心實作這個方法，而只是提供它。
主路由器可讓您使用routeTO()方法直接從JavaScript程式碼呼叫路由。它還根據應用程式的主要路由資訊確定要遵循的有效路線。
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.
以上是使用 Oats~i 建立 Web 應用程式 – 啟動 Oats~i 應用程式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
