Oats~i로 웹 앱 구축 – Oats~i 앱 시작하기

Oats~i 튜토리얼 시리즈의 두 번째 부분에 오신 것을 환영합니다. 첫 번째 부분에서는 개발 환경에 Oats~i를 설치하는 과정을 진행했습니다. 혹시 놓치셨다면 여기에서 확인해 보세요.

이번 시리즈에서는 Oats~i 앱을 시작하는 방법을 살펴보겠습니다. 이는 Oats~i 앱을 시작하고 프런트 엔드에서 프레임워크를 실행하려는 모든 경우를 다룹니다.

전체 프로젝트를 처음부터 구축하는 대신 Oats~i CLI를 사용하여 Oats~i를 설정할 때 Oats~i와 함께 제공되는 내장 시작 프로젝트를 사용하겠습니다. 이 튜토리얼에 필요한 코드의 중요한 부분을 열고 이를 사용하여 Oats~i가 클라이언트/브라우저에 도달하고 웹 앱 실행을 시작할 때 어떻게 로드되는지 설명하겠습니다.

자세히 살펴보겠습니다.

Oats~i CLI를 사용하여 스타터 프로젝트 설치

Oats~i 스타터 프로젝트를 설치할 새 폴더를 만들고 터미널을 엽니다. 그런 다음 다음을 실행하세요.

npx oats-i-cli

안내를 따르세요.

이렇게 하면 Oats~i와 함께 제공되는 시작 프로젝트가 현재 작업 디렉터리에 설치됩니다.

마지막으로 시작 프로젝트를 실행하려면

npm run dev

터미널에 제공된 주소(종종 localhost:8080)로 이동하여 시작 프로젝트가 실행되는 모습을 확인하세요. 사용 가능한 페이지 사이를 오가며 Oats~i가 라우팅을 처리하고 프래그먼트를 통해 뷰를 빌드하는 것을 확인하세요.

이제 클라이언트/브라우저에서 Oats~i를 생생하게 구현하는 코드를 살펴보겠습니다.

Index.js

src에 있는 index.js 파일을 엽니다. -> 앱 -> 인덱스 -> 스크립트.

이 파일에는 cli에 번들로 포함된 시작 프로젝트용 Oats~i를 시작하는 코드가 포함되어 있습니다. 이는 자신의 프로젝트에서 Oats~i를 시작하기 위해 작성하는 코드와 거의 동일합니다.

분해해 보겠습니다.

앱 루트

Oats~i는 일반적으로 appRoot.initApp() 메서드를 통해 appRoot 모듈에서 초기화됩니다.

appRoot는 Oats~i 웹 앱의 초기화, 기본 탐색, 템플릿이 제공되는 경우 루트 보기 로드를 관리하는 AppRoot 클래스의 싱글톤 인스턴스입니다.

initApp() 메서드는 AppStateManager, MainRouter, AppRootView 개체의 인스턴스, 기본 경로, 현재 앱의 외부 링크 차단 동작을 정의할 수 있는 선택적 추가 옵션을 비롯한 여러 인수를 사용합니다.

이를 분석해 보겠습니다.

앱상태관리자

앱 상태 관리자는 Oats~i 앱의 경로 상태를 관리하는 모듈입니다. 주로 Oats~i가 히스토리 팝 이벤트가 사용자가 브라우저에서 앞으로 또는 뒤로 버튼을 클릭한 것인지 이해하는 데 도움이 됩니다.

이 정보는 히스토리 API를 그대로 사용하면 명확하지 않습니다.

Oats~i는 사용자가 웹 앱을 탐색할 때 조각 상태를 저장하기 때문에 이 정보를 갖는 것이 중요합니다. 따라서 이전에 있었던 페이지로 돌아가거나 앞으로 이동하려는 경우 해당 페이지의 렌더링 및 실행을 담당하는 조각은 해당 상태를 "기억"하고 올바른 정보를 표시하며 자동으로 올바른 위치로 스크롤됩니다. 사용자는

에 있었습니다.

팝 이벤트가 전진인지 후진인지 알면 상태 정보를 정확하게 검색할 수 있습니다.

새 앱을 호출하고 웹 앱의 라우팅 정보를 전달하여 AppStateManager의 인스턴스를 생성하기만 하면 됩니다.

index.js 파일에서는 다음 줄에서 이 작업을 수행합니다.

const appStateManager = new AppStateManager(AppRoutingInfo);

이미 AppRoutingInfo를 별도의 파일에 정의했습니다(나중에 자세히 설명).

메인 라우터

메인 라우터는 Oats~i 웹 앱에서 라우팅을 처리합니다. "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.

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.

위 내용은 Oats~i로 웹 앱 구축 – Oats~i 앱 시작하기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!