Frontend Routes and Pages

Nuxt routes are currently defined through Vue page files in the two layers.

Current page entry points

/

  • Source: vipr-frontend/layers/reflectometry/app/pages/index.vue

  • Layer: reflectometry

  • Role: main inference workspace

This page orchestrates the core workflow UI:

  • pipeline step configuration

  • prediction execution

  • results display

  • streaming dashboard

  • result configuration reloading

It depends heavily on reusable stores and composables from both layers, so it is documented as an application entry point rather than as a standalone API surface.

/plugins

  • Source: vipr-frontend/layers/base/app/pages/plugins.vue

  • Layer: base

  • Role: plugin management page

This page coordinates:

  • plugin listing and refresh

  • runtime plugin upload

  • enable/disable operations

  • deletion and batch operations

It is a good example of a page that consumes generated API clients and reusable UI components, but does not itself define much reusable logic.

Why pages are documented separately

The current pages are Vue SFC orchestration shells:

  • they compose auto-imported stores and composables

  • they rely on Nuxt runtime context such as useNuxtApp, useI18n, and route-driven rendering

  • their public contract is the route itself, not a reusable function API

For that reason, the generated frontend reference should focus on reusable TypeScript modules, while page responsibilities stay in hand-written architecture docs.

Planned route documentation growth

As the frontend grows, this section can be extended with:

  • page-level data-flow diagrams

  • route ownership per layer

  • major store/composable dependencies per page

  • cross-links to generated TypeScript reference pages