Feedback and Suggestion: Distributed Configuration for SealedX

[MessiasLima]

Hello SealedX maintainers and community.

I wanted to start a discussion about a potential scalability consideration related to the configuration approach, particularly in larger applications.

Typical SealedX Configuration

As I understand it, a common way to configure SealedX to generate sealed interfaces for different models (like UI states for various screens) is using the @ExtensiveSealed annotation like this:

@ExtensiveSealed(
  models = [
    ExtensiveModel(Poster::class),
    ExtensiveModel(PosterDetails::class),
    // ... potentially many more models
  ]
)
sealed interface CommonUiStateBase { // The base interface might vary
  data class Success(val data: Extensive) : CommonUiStateBase
  object Loading : CommonUiStateBase
  object Error : CommonUiStateBase
}

This setup then generates individual sealed interfaces for each model listed, such as PosterUiState, PosterDetailsUiState, etc., based on the structure defined in CommonUiStateBase.

The Scalability Concern

My observation is that in a growing application, the models array within this central @ExtensiveSealed annotation will need to list every single model or ViewModel for which a dedicated UI state sealed class is required.

If an application has 50 screens, and each screen has a unique data model requiring a generated state (e.g., Screen1Model, Screen2Model, …, Screen50Model), this list would grow to include 50 ExtensiveModel entries. For 100 screens, it would contain 100 entries, and so on.

This growth of a single configuration list raises concerns as the application scales.

Coupling and Merge Conflicts

Concentrating the configuration for code generation of many disparate parts of the application into a single annotation instance creates a point of high coupling. Any time a new screen or feature is added or an existing one is removed, this specific file containing the annotation must be modified.

In a team environment, this significantly increases the likelihood of frequent merge conflicts in this single file as multiple developers simultaneously add entries for the new features they are working on. Managing these conflicts can become a recurring overhead.

Proposed Solution: Distributed Configuration

A potential way to address this scalability and coupling issue could be to allow for a more distributed configuration approach. Instead of listing all models in one central place, the KSP processor could be designed to discover models requiring generated states by looking for an annotation applied directly to the model or ViewModel class itself.

For example, a hypothetical annotation like @GenerateUiState could be applied directly to the model classes:

// In your feature/poster module file
@GenerateUiState // KSP finds this annotation
data class Poster(...)

// In your feature/posterdetails module file
@GenerateUiState // KSP finds this annotation
data class PosterDetails(...)

In this scenario, the KSP processor would scan the project (or module) for classes annotated with @GenerateUiState and generate the corresponding sealed state interfaces (PosterUiState, PosterDetailsUiState, etc.) based on a pre-defined template (perhaps still configured once globally or per module, but without listing every single model).

Benefits of Distributed Configuration

This distributed approach offers several benefits:
• No Monolithic Annotation: Eliminates the single, ever-growing list of models.
• Improved Locality: The configuration for generating a state for Poster lives with the Poster class, improving code organization and discoverability.
• Reduced Merge Conflicts: Changes to generation configuration are localized to the file/feature being worked on.
• Better Alignment with Modularization: Fits more naturally into a modular project structure where features are developed and configured more independently.

Thank you for considering this feedback and for your work on SealedX! I’m interested to hear the community’s thoughts on this.

Best regards