pragadeesvp/sterna_assesment

Purpose and Runtime

This is an Angular 21 single-page desktop-oriented preview application for a login-gated dashboard. It is built and served through Angular CLI, with the browser as its runtime; the README identifies a Netlify-hosted demo but no backend API or external data service.

Entry bootstrap:

• src/main.ts

• src/app/app.module.ts

• src/app/app.component.ts

Application Shell and Composition

AppModule assembles the application’s components, routing, Angular Material theme, and shared Angular dependencies. The root component provides the top-level router outlet and global styling boundary.

Key shell paths:

• src/app/app.component.ts

• src/app/app.component.html

• src/material-theme.scss

Global document and application styles originate in:

• src/index.html

• src/styles.css

Route-Controlled Screens

Routing separates the public login screen from protected application views. The major route-level destinations are login, dashboard, and location; the layout component likely acts as the authenticated page frame around protected content.

Route and screen paths:

• src/app/app-routing.module.ts

• src/app/login/login.component.ts

• src/app/dashboard/dashboard.component.ts

• src/app/location/location.component.ts

Authentication Boundary

Authentication is client-side and intentionally lightweight: the README supplies accepted email identities and states that any six-letter password is valid. The route guard is the enforcement boundary preventing unauthenticated navigation to protected routes.

Authentication paths:

• src/app/login/login.component.ts

• src/app/guards/auth.guard.ts

• src/app/app-routing.module.ts

Primary control flow: user submits login credentials → login component establishes client-side authenticated state → router navigates toward protected content → guard permits or redirects navigation based on that state.

Authenticated Layout and Navigation

The layout component owns persistent authenticated UI structure, such as navigation and content placement, while routed feature components render inside that frame. This isolates chrome/navigation concerns from dashboard and location-specific presentation.

Layout paths:

• src/app/layout/layout.component.ts

• src/app/layout/layout.component.html

• src/app/app-routing.module.ts

Data Provisioning

A centralized Angular service is the application’s data-access boundary. Given the absence of server configuration or documented API dependencies, it likely provides in-memory/static data consumed by dashboard and location views rather than performing remote persistence.

Data boundary paths:

• src/app/services/data.service.ts

• src/app/dashboard/dashboard.component.ts

• src/app/location/location.component.ts

Primary data flow: feature component requests view data from DataService → component transforms/binds it into its template → Angular change detection renders the dashboard or location view.

Infrastructure and Delivery

The project uses Angular CLI configuration for local serve and production builds, npm for dependency management, and appears deployable as static frontend assets; the demo is hosted on Netlify. Angular Material theming is configured locally rather than via an external design-system service.

Infrastructure paths:

• angular.json

• package.json

• src/material-theme.scss