Future Improvements

This page documents the content resolution architecture and what has been implemented.

Implemented: Typed Block DTOs with Auto-Hydration

Status: ✅ Implemented in v1.1.0

The recommended approach has been fully implemented across all three packages. See Content Resolution and Block DTOs for the current system.

What Was Implemented

graph TD
    subgraph "v1.0.0 (Old)"
        A[ContentResolver] -->|groups by type| B[SectionContent]
        B -->|__get magic| C[BlockData]
        D[hydrateFromContent] -->|manual mapping| E[Component Properties]
        F[HasFieldLabels] -->|manual labels| G[Field Labels]
    end
    
    subgraph "v1.1.0 (New)"
        H[BlockCaster] -->|Eloquent cast| I[BlockCollection]
        I -->|typed access| J[BlockData]
        K[autoHydrate] -->|reflection| L[Component Properties]
        M[BlockSchemaExtractor] -->|auto-extract| N[Field Labels]
    end
    
    A -.->|removed| H
    B -.->|removed| I
    D -.->|removed| K
    F -.->|removed| M

Key Changes

Aspect	v1.0.0	v1.1.0
Resolution	`ContentResolver` class	`BlockCaster` Eloquent cast
Container	`SectionContent`	`BlockCollection`
Block access	`__get` magic	`$block->get()`
Null handling	`NullBlockData`	`null` from `first()`
Hydration	Manual `hydrateFromContent()`	Automatic `autoHydrate()`
Labels	Manual `fieldLabels()`	Auto-extracted `BlockSchemaExtractor`
Ordering	Grouped by type	Original array order preserved
Livewire serialization	Manual	`public $blockData` + `hydrate()`

Migration Guide

See Migration Guide for step-by-step instructions to migrate from v1.0.0 to v1.1.0.

Alternative Approaches (Not Implemented)

These approaches were considered but not chosen. They may be useful for understanding the design space.

Pipeline-Based Resolution

Replace the monolithic resolution with a Laravel Pipeline:

graph LR
    A[Section] -->|pipeline| B[DecodeJson]
    B -->|pipeline| C[ResolveBlocks]
    C -->|pipeline| D[AttachSourceMaps]
    D -->|pipeline| E[ResolvedSection]

Pros: Extensible, testable stages, declarative property mapping Cons: More moving parts, over-engineered for most use cases

Section View Models

Each section type gets a dedicated View Model class:

graph LR
    A[Section] -->|SectionResolver| B[HeroViewModel]
    B -->|typed| C[Livewire Component]

Pros: Full type safety, IDE autocomplete, rich behavior Cons: More boilerplate, one class per section type

Future Considerations

Performance Optimizations

BlockCaster caching — Cache decoded BlockCollection within request lifecycle
Eager loading optimization — Reduce N+1 queries for sections with many blocks
Lazy block resolution — Only resolve blocks that are actually rendered

Type Safety Improvements

PHPStan integration — Add static analysis for block data access
IDE plugins — Auto-complete for BlockData::get() calls
Generics — BlockCollection<T> for typed collections

Extensibility

Custom BlockData DTOs — Register typed DTOs for specific block types
Pipeline-based resolution — Optional pipeline for complex transformations
Event system — Fires events during resolution for middleware-like behavior