Add a class-based component() helper for reusable view components

[armanist]

Summary

Add a first version of view components to Quantum through a class-based helper:

• component('ComponentName', array $params = [])

This should provide a more structured alternative to partial() for reusable view fragments with their own class logic and rendering behavior.

Why

Quantum already has:

• partial()

which is useful for simple reusable view fragments, but it is only a direct partial render/include mechanism.

A component system should support a more sophisticated approach where a reusable view fragment is backed by a class that can:

• accept params
• prepare internal state in __construct()
• render its own partial through render()

This is the first step toward a broader component model inspired by frameworks such as Vue, React, Angular, Laravel Blade components, and similar PHP approaches, without introducing tag parsing yet.

Goal

Introduce a minimal component runtime for Quantum that allows views to render reusable class-backed components through a helper call.

Proposed Direction

Add a helper such as:

component('Alert', [
    'type' => 'error',
    'message' => 'Something went wrong',
]);

The helper should:

1. resolve the component class
2. instantiate it with the provided params
3. call its render() method
4. return the rendered string output

First version scope

This first version should stay intentionally minimal.

It should support:

• a class-based component model
• constructor-based param handling
• string rendering through render()

It should not yet include:

• XHTML parsing
• <x-...> tag syntax
• slot support
• anonymous/file-only components
• advanced component templating syntax

Those can come later.

Component contract

The first version should keep the component API small.

A likely minimal shape is:

• __construct(array $params = [])
• render(): string

This allows the component class to normalize params and render its own partial or output.

Rendering behavior

A component should typically render through the existing view/partial rendering system, rather than bypassing it.

That keeps the feature aligned with Quantum’s current view architecture and allows the helper to work with the existing rendering model.

Nesting behavior

Components should be allowed to render other components.

That means:

• component nesting is supported
• normal repeated component usage is allowed

However, circular component rendering must be detected and blocked.

Examples that must fail:

• component A renders A
• component A renders B, and B renders A

This first version should include circular-render detection through an active render stack.

It does not need a configurable max-depth setting in the first version.

Why this version first

The long-term direction may include an XHTML renderer that parses tags like:

• <x-alert>
• <x-post-card>

But that should be treated as a later version.

The first version should establish the component class contract and helper-based runtime first, so future XHTML parsing can build on the same component model instead of introducing a second one.

Acceptance Criteria

• a global/helper-level component() API exists
• the helper resolves and instantiates component classes
• params can be passed into component constructors as an array
• component classes return rendered output through render(): string
• components can render other components
• circular component rendering is detected and blocked
• partial() remains available for simpler use cases
• tests cover basic rendering, param passing, nesting, and circular recursion detection

Notes

Relevant code:

• src/View/Helpers/view.php
• src/View/View.php
• src/Renderer/Adapters/HtmlAdapter.php
• src/Renderer/Adapters/TwigAdapter.php

This ticket is the minimal component-runtime foundation and should come before any XHTML or <x-...> parsing work.