block-decision-matrix

To decide whether to reuse a UI component or create a new block, evaluate semantic purpose, structural similarity, required custom fields, and conditional logic complexity. A decision framework analyzes these factors to prevent code duplication and over-engineering in frontend architecture.

A Frankenstein Block in component design is an anti-pattern where a UI component is overloaded with too many custom fields and conditional logic. Identifying this pitfall helps maintain scalable UI architectures by avoiding God Components and ensuring proper block strategy.

You should create a variant of an existing block instead of a new block when the new UI component shares structural similarity and semantic purpose with the existing one, but requires minor custom field adjustments. Complexity thresholds guide this decision to maintain frontend reusability.

Limitations of using a decision matrix for frontend architecture include relying on quantifiable metrics like props count and conditionals, which may not fully capture nuanced design semantics. It guides block strategy effectively but requires accurate structural analysis to avoid misclassifying component variations.

You use complexity thresholds to guide component development by measuring props count and conditional logic complexity against predefined metrics. If a UI component exceeds these thresholds, the decision framework suggests implementing a new block rather than forcing a variant to ensure maintainable code.