Available for Use?

Just working on the search_api_postgresql module to get it ready for 1.x release. Then back onto the component_field, component_block, component_view, and component_search modules. I will be looking at creating the first developer release in about a week. The code is available in the repository - you can just install it manually and take a look. Still needs work, though.

Always keen for extra help, so if you have time, feel free to volunteer as a co-maintainer for any of the modules I'm working on if you see value in them. I generally push code first to my public GitHub, then onto Drupal.org. These modules are part of a project I'm working on at the moment, where I saw the UI patterns module and other offerings were not quite what I was looking for.

Many thanks for the update! I have been really interested in the UI Patterns and other work around this. Just in case you haven't seen them already, there are the Single Directory Components: Display → and Single Directory Components: Block → modules which look like there may be some crossover with your SDC modules?

I am a site builder rather than developer but happy to help with testing or documentation if needed.

Component Field vs SDC Display: A Comprehensive Comparison (my take)

Core Philosophy Differences

SDC Display Module

SDC Display allows site builders to leverage components within the "Manage Display" tabs of entities, configuring what component an individual field uses or what component a given view mode uses. It's essentially a display formatter approach that maps existing content to component templates.

This module works by to use component-based rendering without changing the underlying content creation workflow.

Component Field + Component Block

This combination creates new content creation paradigms with dedicated field types and block content types, providing full component configuration interfaces during content creation.

This approach puts of the content creation process, allowing content creators to directly configure component properties with rich interfaces.

Content Creation Approach

SDC Display Method

Content Model: Uses existing entities and fields without modification. Content creators continue using familiar Drupal field types, while site builders map this data to components at the display layer.

Configuration Timing: All component mapping happens at through the Manage Display tab interface.

SDC Display supports rendering at field level, field group level (via Field Group module), and entity level, allowing for flexible component integration across different content structures.

Component Field Method

Content Model: Creates new field types and block content types specifically designed for component configuration. Content creators work directly with component-aware interfaces.

Configuration Timing: Component configuration happens at with dynamic form generation based on component schemas.

Configuration Capabilities

SDC Display Limitations and Strengths

SDC Display is limited to mapping existing field values to component props. For complex transformations, it requires the SDC Display Preprocess module, which allows developers to modify props and slots before they reach templates through preprocess files within component directories.

The module provides a simple component selector in the Manage Display UI but cannot create rich configuration interfaces for components with complex property requirements.

Component Field Advanced Configuration

Component Field provides comprehensive configuration capabilities including:

Rich Text Integration: Full CKEditor5 integration for text properties with proper HTML handling and format support.

Entity References: Support for media, nodes, and taxonomy terms with proper validation and rendering.

Complex Data Types: Arrays, objects, and JSON configuration with validation against component schemas.

Live Preview: Real-time component rendering during the editing process.

Multi-Component Support: Multiple components per field or block with drag-and-drop reordering capabilities.

User Experience Comparison

SDC Display Advantages

Familiar Workflow: Uses existing Manage Display tabs that site builders already understand.

Existing Content: Works with current content structure without requiring content migration.

Quick Implementation: Component selection happens at the theme/display level with minimal setup.

SDC Display Limitations

Limited Configuration: Cannot create rich interfaces for complex component properties.

Data Mapping Constraints: Restricted to existing field data structures.

No Content Creator Visibility: Content creators don't see or configure components directly.

Component Field Advantages

Component-First Workflow: Content creators work directly with component interfaces.

Rich Configuration: Dynamic form generation with validation, previews, and advanced field types.

Analytics and Management: Usage statistics, version tracking, and comprehensive admin interfaces.

Component Field Complexity

Learning Curve: New content creation paradigm requires user training.

Development Overhead: More complex codebase with extensive features to maintain.

Content Migration: Existing sites need content migration to adopt the new approach.

Technical Architecture

SDC Display Architecture

SDC Display provides a lightweight integration with existing Drupal systems. It leverages the existing display pipeline and works at three distinct levels: field level, field group level, and entity level.

The module works when fields can be formatted to fit component variables, but has limits if customizations are needed. SDC Display Preprocess module provides a way to handle complex transformations.

Component Field Architecture

Component Field implements a comprehensive field system with extensive features:

Advanced Caching: Performance optimization with intelligent cache invalidation and version tracking.

Search Integration: Search API integration for component content with automatic text extraction.

AJAX Handling: Complex AJAX functionality with CKEditor5 support and proper form state management.

Error Handling: Comprehensive validation and error recovery throughout the system.

Development Complexity Analysis

SDC Display: Simpler Implementation

SDC Display builds on existing Drupal patterns with minimal additional complexity. The codebase is focused and leverages established systems, making it easier to maintain and extend.

Component Field: Extensive Feature Set

Component Field represents a comprehensive solution with over 20 files and 3000+ lines of code. It includes advanced features like search integration, analytics, version tracking, and complex form handling, but requires significant development and maintenance effort.

Use Case Scenarios

Choose SDC Display When:

Retrofitting Existing Sites: You have existing content and want to enhance how it renders using components without changing the content creation workflow.

Simple Component Mapping: Your components primarily need existing field data with minimal transformation requirements.

Display-Focused Changes: You want to change how existing content renders without affecting the authoring experience.

Field Group Integration: You want to render groups of fields using components via the Field Group module.

Minimal Development Overhead: You prefer leveraging existing Drupal patterns rather than implementing custom solutions.

Choose Component Field + Component Block When:

Component-First Content Strategy: You want content creators to think in terms of components from the beginning of the content creation process.

Complex Component Configuration: Your components need rich configuration interfaces with validation, previews, and advanced field types.

Rich Text Integration: Components need CKEditor5-enabled text properties with proper HTML handling.

Reusable Component Blocks: You want component-based custom blocks that can be placed throughout the site.

Advanced Features: You need analytics, version tracking, search integration, and comprehensive management tools.

Multi-Component Layouts: You want multiple components per field or block with reordering capabilities.

Migration Considerations

From SDC Display to Component Field

Migration would require content restructuring since the data models are fundamentally different. However, this migration would unlock significantly richer functionality and component-first workflows.

From Component Field to SDC Display

You could potentially map component field data to display templates, but this would result in loss of advanced configuration capabilities and the rich authoring experience.

Final Recommendation

SDC Display is ideal for enhancing existing sites with component-based rendering while maintaining familiar workflows. It's perfect for organisations that want to leverage components for display without changing their content creation processes.

Component Field + Component Block is the choice for organisations building component-first content strategies. It provides a complete ecosystem for component-based content creation with advanced features, but requires a commitment to the new paradigm.

Component Field + Component Block vs SDC Block: A Comprehensive Comparison

Core Philosophy Differences

SDC Block Module

Auto-Generation Approach: "Write Single Directory Components, and get blocks for free! This module will provide one block type for each component tagged using SDC Tagging. A configuration form will be auto-generated for your block, even if your component uses props or contains slots. No additional effort required."

SDC Block takes a minimal intervention approach - it automatically converts existing SDC components into block types without requiring additional development effort. The module relies entirely on component YAML schemas to generate configuration forms.

Component Field + Component Block

This combination provides a comprehensive content creation ecosystem with dedicated block content types, rich configuration interfaces, advanced features like analytics and version tracking, and purpose-built admin experiences for component-based content creation.

This approach treats with full Drupal entity capabilities, custom workflows, and extensive feature sets beyond basic component rendering.

Content Creation and Management

SDC Block Method

Automatic Block Generation: "The module provides one block type for each component tagged using SDC Tagging and a configuration form is auto-generated for your block, even if your component uses props or contains slots."

Configuration Source: All configuration options come directly from the component's .component.yml file. The module automatically generates form fields based on prop definitions and slot declarations.

Block Placement: Uses standard Drupal block placement through /admin/structure/block interface. Site builders select components from the auto-generated block types list.

Component Field + Component Block Method

Custom Block Content Type: Creates a dedicated "Component Block" content type with unlimited component field instances, allowing multiple components per block with reordering capabilities.

Rich Configuration Interface: Dynamic form generation with validation, live preview, CKEditor5 integration, entity references, and complex data type support beyond basic component schemas.

Content-Centric Workflow: Blocks are created through the custom block content interface with comprehensive management, versioning, and analytics capabilities.

Configuration Capabilities Comparison

SDC Block Configuration

Schema-Driven Forms: Configuration forms are automatically generated from component prop definitions. A string prop becomes a text field, boolean props become checkboxes, etc.

Token Integration: "When a site builder puts a block on a page that contains a node, then they can use the node information in the CL Block using tokens. Access the node content (and its relationships) using tokens. For instance: [node:title]."

Slot Support: Automatically handles component slots for unstructured content alongside structured props.

Limitations: Configuration is limited to what can be auto-generated from basic YAML schema definitions. No rich text editing, complex validation, or advanced field types.

Component Field Configuration

Advanced Form Generation: Supports rich text fields with CKEditor5, entity references (media, nodes, taxonomy), complex data types (arrays, objects), and JSON configuration with validation.

Live Preview System: Real-time component rendering during configuration with proper error handling and fallback states.

Multi-Component Support: Multiple components per block with drag-and-drop reordering, component versioning, and configuration validation against schemas.

Rich Text Integration: Full CKEditor5 support with proper HTML handling, text formats, and content processing - features not available in auto-generated forms.

Technical Architecture Analysis

SDC Block Architecture

Lightweight Plugin System: Creates block plugins dynamically based on discovered SDC components. Each tagged component automatically becomes a block type with minimal overhead.

Schema Dependency: Entirely dependent on component YAML schemas for form generation. Cannot extend beyond what's defined in the component metadata.

Standard Block API: Uses Drupal's core block system without modification, ensuring compatibility with Layout Builder and other block-rendering tools.

SDC Block works by scanning for components tagged with SDC Tagging and automatically generating corresponding block plugins with configuration forms derived from component schemas.

Component Field Architecture

Comprehensive Field System: Implements custom field types, formatters, widgets, and storage schemas with extensive error handling and validation.

Advanced Features: Search API integration, analytics dashboard, version tracking, cache management, and complex AJAX handling with CKEditor5 support.

Custom Content Type: Creates dedicated block content entities with full entity capabilities including revisions, translations, and workflow integration.

Development and Maintenance

SDC Block Development

Minimal Setup: Install module, tag components with SDC Tagging, and blocks are automatically available. No additional development required.

Zero Configuration: Block forms are automatically generated from existing component definitions without manual intervention.

Limited Customization: Customization is restricted to what can be expressed in component YAML schemas. Complex form logic or validation requires component-level modifications.

SDC Block Advantages

Instant Blocks: Components immediately become available as blocks without additional development effort.

Automatic Updates: Changes to component schemas automatically update block configuration forms.

Low Maintenance: Minimal codebase to maintain since functionality is auto-generated.

SDC Block Limitations

Beta Stability: Module is currently in beta with no stable release, limiting production use.

Configuration Constraints: Limited to basic form elements that can be auto-generated from YAML schemas.

No Advanced Features: Lacks analytics, version tracking, search integration, or advanced admin interfaces.

Component Field Development

Extensive Codebase: Over 20 files and 3000+ lines of code providing comprehensive functionality but requiring significant maintenance.

Advanced Feature Set: Rich configuration interfaces, analytics, version tracking, search integration, and comprehensive error handling.

Custom Development Required: Requires understanding of Drupal field API, custom entity types, and complex form handling.

Component Field Advantages

Rich User Experience: Advanced configuration interfaces with live preview, validation, and comprehensive admin tools.

Extensible Architecture: Can support any component configuration scenario through custom form generation.

Enterprise Features: Analytics, version tracking, search integration, and comprehensive content management capabilities.

Component Field Complexity

Development Overhead: Significant codebase requiring ongoing maintenance and Drupal expertise.

Learning Curve: Complex architecture requiring training for both developers and content creators.

Overkill for Simple Use Cases: May be unnecessarily complex for basic component block needs.

Use Case Scenarios

Choose SDC Block When:

Existing SDC Components: You already have well-defined SDC components and want instant block availability without additional development.

Simple Configuration Needs: Your components have straightforward props that work well with auto-generated forms (strings, numbers, booleans).

Quick Implementation: You need component blocks immediately with minimal development investment.

Layout Builder Integration: You want components automatically available in Layout Builder and other block-based tools.

Minimal Maintenance: You prefer zero-maintenance solutions that automatically adapt to component changes.

Token-Based Content: Your components primarily need access to contextual node data through tokens rather than custom configuration.

Choose Component Field + Component Block When:

Rich Configuration Requirements: Your components need advanced configuration interfaces with rich text, entity references, or complex data types.

Multi-Component Blocks: You want to combine multiple components within single blocks with reordering capabilities.

Content Management Features: You need analytics, version tracking, search integration, and comprehensive admin interfaces.

Custom Validation and Logic: Your components require complex validation rules or conditional form logic beyond basic schemas.

Enterprise Content Strategy: You're building a comprehensive component-based content system with advanced features and reporting.

CKEditor5 Integration: Your components need rich text properties with proper HTML handling and format support.

Integration and Compatibility

SDC Block Integration

Core Block System: Full compatibility with Drupal's block system, Layout Builder, and any tool that renders blocks.

SDC Ecosystem: Works seamlessly with other SDC modules like SDC Display and SDC Tagging.

Theme Integration: Automatically discovers components from theme directories without additional configuration.

Component Field Integration

Search API: Automatic content extraction and indexing for component-based content.

Entity System: Full Drupal entity capabilities including workflows, translations, and revisions.

Custom Field Type: Can be used beyond blocks - works as field type for any entity bundle.

Performance and Scalability

SDC Block Performance

Lightweight Operation: Minimal overhead since forms are auto-generated and cached.

Standard Caching: Benefits from Drupal's standard block caching without custom cache management.

Simple Data Storage: Uses standard block configuration storage without complex data structures.

Component Field Performance

Advanced Caching: Sophisticated cache management with version tracking and intelligent invalidation.

Complex Data Handling: Efficient processing of rich configuration data, entity references, and search indexing.

Performance Optimization: Lazy loading, efficient AJAX handling, and optimized database queries.

Migration and Upgrade Paths

From SDC Block to Component Field

Migration would require content restructuring from block configuration to block content entities. However, component definitions could potentially be preserved and enhanced with richer configuration options.

From Component Field to SDC Block

Downgrading would result in significant functionality loss including rich text capabilities, multi-component support, analytics, and advanced admin features. Component configurations would need simplification to fit auto-generated form constraints.

Module Stability and Support

SDC Block Status

Beta Release: Currently in beta with no stable release, which may limit production adoption until stability is proven.

Community Driven: Active development by the SDC community with integration into the broader SDC ecosystem.

Component Field Status

Production Ready (sort of): Comprehensive implementation with extensive error handling and validation suitable for production use.

Custom Solution: Requires ongoing maintenance and support as a custom module rather than community-supported contrib module.

Final thoughts

Choose SDC Block if you want immediate, zero-effort block generation from existing SDC components with simple configuration needs. It's perfect for rapid prototyping, simple component blocks, and scenarios where auto-generated forms meet your requirements.

Choose Component Field + Component Block if you need a comprehensive component-based content management system with advanced features like rich text editing, multi-component blocks, analytics, version tracking, and enterprise-level functionality.

Hybrid Approach Consideration

For organisations with mixed needs, consider using SDC Block for simple components that work well with auto-generated forms, while implementing Component Field for complex components requiring advanced configuration interfaces. This provides the best of both worlds - instant blocks for simple use cases and powerful tools for complex requirements.

Thanks so much @code-poet, that is a really helpful and thorough comparison. I hadn't thought about the implications of things like search capabilities, integration with the entity system, rich configuration and the many other capabilities Component Field and Component Block will include. Looking forward to trying them out! Thank you for taking the time to detail the differences.