欢迎来到使用 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中文网其他相关文章！
