Skip to content
Paulo Gomes da Cruz Junior edited this page Jun 16, 2026 · 5 revisions

Layout

Layout is the application's shell component. It creates the shared Carbon page frame by combining LayoutProvider, HeaderContainer, LayoutHeader, and the main content grid around page content passed in as children.

Rationale

Use Layout once at the shell boundary so pages inherit consistent header, side-navigation, and content-grid behavior without re-wiring layout context or Carbon shell primitives on every route.

Source References

  • Source: frontend/src/components/Layout/index.tsx
  • Tests: frontend/src/components/Layout/index.unit.test.tsx

Props

Name Type Required Description
children ReactNode Yes Page content rendered inside the shell's main Grid.

Behavior

  • Creates its own LayoutProvider for side-nav and header-panel state.
  • Renders Carbon HeaderContainer with LayoutHeader as the shell header.
  • Wraps page content in Carbon Content and a no-gutter Grid with the layout-grid class.
  • Leaves route rendering and higher-level providers outside the component; it only owns the shell frame.

Examples

Happy path: route page inside the shared shell

import Layout from '@/components/Layout';
import PageTitle from '@/components/core/PageTitle';

const WasteSearchPage = () => {
  return (
    <Layout>
      <PageTitle title="Waste Search" subtitle="Browse and refine results" />
      <section>...</section>
    </Layout>
  );
};

Edge case: route-level error content still uses the same shell

import Layout from '@/components/Layout';
import GlobalErrorPage from '@/pages/GlobalError';

const RouteErrorView = () => {
  return (
    <Layout>
      <GlobalErrorPage />
    </Layout>
  );
};

Dependencies

Layout creates LayoutProvider itself, but the composed header and side-nav experience still expect these providers above the shell:

  • RouterProvider
  • AuthProvider
  • PreferenceProvider
  • ThemeProvider
  • QueryClientProvider

Known Constraints

  • Layout should be used once at the application-shell level, not nested inside page components.
  • Any child content is rendered inside a single no-gutter grid; page-specific spacing should be handled by the child page content.
  • Although the shell owns LayoutProvider, the header subtree still depends on routing, auth, theme, and preference providers supplied higher in the app.

Change Impact

  • codes/frontend/Components.md — catalog entry points to this page.
  • codes/frontend/Layout/LayoutHeader.md — documents the header rendered by this shell.
  • codes/frontend/Layout/LayoutSideNav.md — documents the navigation rendered by this shell.

See Also

Waste Plus Wiki

Home

Architecture

Codes

Decisions

Knowledge Base

Development

Changes

Clone this wiki locally