RFC: Make selectors optional (In treaty)

[Jordan-Hall]

Description

Within the Angular ecosystem, selectors are pivotal for the identification of components, directives, or pipes, simplifying their referencing within templates. Despite this critical role, a prevalent practice among developers involves employing selectors in a basic manner, typically by matching them directly with class names, e.g., "selector-name" or [name]. While this method ensures consistency, it may not fully harness the selectors' potential, often leading to redundancy and confusion.

Consider the conventional practice:

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html',
  styleUrls: ['./example.component.css']
})
export class ExampleComponent {}

This common approach, aligning selectors with class names, fails to capitalize on the full capabilities and flexibility that selectors can offer, pointing towards an opportunity for optimization to enhance the developer experience (DX) in Angular.

Proposed Solution for TreatyJs

To bolster the DX within TreatyJs—a metaframework built on Angular that supports its own authoring process—we propose a novel approach to handling selectors. By making selector declarations optional, we aim to streamline the definition process for components and directives. When a selector is not explicitly provided, the TreatyJs compiler, much like Angular's, would default to using the class name as the selector. However, it would sidestep Angular-specific keywords such as Pipe, Component, and Directive, thereby simplifying component referencing within templates.

A significant feature of this proposal is the introduction of dual selector naming conventions: kebab-case for compliance with HTML standards and enhanced readability, and PascalCase to align with TypeScript class naming conventions. This dual-definition strategy ensures TreatyJs remains versatile and accessible to developers with varying preferences.

Illustration of Automatic Selector Generation in TreatyJs:

Given a class named InfoPanelComponent, TreatyJs would automatically generate two selector formats:

• Kebab-case: info-panel
• PascalCase: InfoPanel

This facilitates flexible component utilization in templates, whether following HTML naming standards or leveraging TypeScript's PascalCase, as illustrated below:

@Component({
  templateUrl: './info-panel.component.html',
  styleUrls: ['./info-panel.component.css']
})
export class InfoPanelComponent {}
// TreatyJs automatically generates the selectors: 'info-panel' and 'InfoPanel'

Furthermore, this streamlined approach extends to directives and pipes, ensuring a cohesive and intuitive workflow across TreatyJs development.

Integration of Components, Directives, and Pipes in Templates

In TreatyJs templates, components, directives, and pipes with automatically generated selectors can be used seamlessly:

<!-- Component usage with auto-generated selectors -->
<info-panel></info-panel>
<InfoPanel></InfoPanel>

<!-- Directive application -->
<div highlight>Highlighted text here.</div>

<!-- Pipe usage -->
{{ 'Sample Text' | formatText }}

This example demonstrates the utilization of TreatyJs's automatic selector generation for a unified, efficient development process across components, directives, and pipes.

Configurable Naming in TreatyJs

To cater to diverse project requirements, TreatyJs supports configurable naming conventions, potentially enforced via tools like ESLint, to maintain consistency across projects.

Example ESLint Rules for TreatyJs:

{
  "rules": {
    "angular-selector-prefix": [true, "app"],
    "angular-selector-suffix": [true, "cmp"]
  }
}

These rules facilitate a cohesive naming strategy, whether for auto-generated or manually defined selectors, underscoring our commitment to an enhanced DX within TreatyJs.

Alternatives Considered

While some have suggested removing selectors entirely, this proposal recognizes their essential role in the framework's architecture. Selectors enable versatile component identification and interaction, a feature too critical to forego for the sake of simplicity.

Summary and TreatyJs Specifics

This RFC, tailored for TreatyJs and discussed within our (Treaty) repository, addresses Angular's DX shortcomings by advocating for automated selector generation and dual naming conventions. This advancement not only diminishes redundancy and confusion but also augments the robust and adaptable framework of TreatyJs. It's imperative to note that these changes are exclusive to TreatyJs and its libraries, which are fully compatible with Angular, thanks to Ivy compilation. This proposal underscores our commitment to enhancing the authoring experience within TreatyJs, ensuring a seamless and productive development process.