quantum-php / quantum-php/framework
Add a class-based component() helper for reusable view components
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Description
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:
- resolve the component class
- instantiate it with the provided params
- call its
render()method - 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
ArendersA - component
ArendersB, andBrendersA
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.phpsrc/View/View.phpsrc/Renderer/Adapters/HtmlAdapter.phpsrc/Renderer/Adapters/TwigAdapter.php
This ticket is the minimal component-runtime foundation and should come before any XHTML or <x-...> parsing work.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading src/View/Helpers/view.php and src/View/View.php to understand how partial() and view rendering work, then inspect the HtmlAdapter.php and TwigAdapter.php files. Define the minimal helper, constructor and render contract, nested rendering behavior, and active-stack circular detection. Done means the acceptance criteria are covered by tests for rendering, params, nesting, and recursion detection while partial() remains available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100