The last section covered a basic plugin architecture, designed to separate the project code by unit feature and allowing developers to progressively toggle each one at any given time. Get caught up by making sure your project looks like the following.

If you are all caught up, then you can proceed to the next section.

From the project root, create a file called plugins/app/pages/home.ts with the following code.

This basically consumes the data from the request. Data from a request is a merge of query params, POST data, and URL params respectively. Consider the following request.

In the example above, assuming the requested pathname is , the return of will be computed as where as URL params has priority over POST data which has priority over query params. Lastly, the is passed to the response via .

Next let's change the plugins/app/plugin.ts file with the following code.

Now in the handler a route has been added that will lazily load the page when the path is requested. Similar to React suspense loading, the reason why lazily loading page routes is recommended is because it will allow bundlers to theoretically analyze the code and possibly split it into smaller chunks. We also want to de-prioritize the view by adding a priority to ensure it loads last. This allows other plugins to inject themselves in the routing phase.

To consume the in the view, you can use the argument in the following way.

You should observe that by adding the flag you can check the server props being sent to your view. This is different from /api/home where the home page route is treated as an API endpoint.

In case you got lost along the way, here is a checkpoint of what your project should look like.

The next section will cover how server props works, how to send custom template data and how the view consumes it.