WIDGET CONSOLIDATION ANALYSIS

Comprehensive guidelines for AI-assisted development within the Editor platform

🔍 Widget/Embeddable Duplication Analysis

Date: December 6, 2024
Status: 🚨 DUPLICATES FOUND
Impact: HIGH (code maintenance, bundle size, confusion)

🎯 The Problem

We have SIGNIFICANT DUPLICATION across our component libraries:

❌ Same component exists in MULTIPLE places:
├── libs-widgets/widgets (full widgets)
├── libs-ui-core/ui-core (embeddables)
└── libs-ui-core/ui-forms (form embeddables)

📊 Duplicate Components Found

Category 1: UI Components (12 duplicates)

Component	widgets/widgets	ui-core	ui-forms	Status
breadcrumb	✅	✅	❌	⚠️ DUPLICATE
card	✅ (card-widget)	✅	❌	⚠️ DUPLICATE
chip	✅	✅	❌	⚠️ DUPLICATE
chip-list	✅	✅	❌	⚠️ DUPLICATE
clipboard	✅	✅	❌	⚠️ DUPLICATE
context-menu	✅	✅	❌	⚠️ DUPLICATE
editable-slug	✅	✅	❌	⚠️ DUPLICATE
icon/icons	✅ (icon-widget)	✅	❌	⚠️ DUPLICATE
input	✅ (input-widget)	✅	❌	⚠️ DUPLICATE
module-dock-slot	✅	✅	❌	⚠️ DUPLICATE
simple-tabs	✅	✅	❌	⚠️ DUPLICATE
ux-tabs	✅	✅	❌	⚠️ DUPLICATE

Category 2: Form Components (2 duplicates)

Component	widgets/widgets	ui-core	ui-forms	Status
checkbox	✅ (checkbox-widget)	❌	✅	⚠️ DUPLICATE
select	✅ (select-widget)	❌	✅ (ux-select)	⚠️ DUPLICATE

Category 4: Unique to ui-core (Embeddables ✅)

ui-button ✅ (used by button-widget - CORRECT pattern!)

Category 5: Unique to ui-forms (Form Embeddables ✅)

color-picker ✅
form-field ✅
multi-select ✅
toggle ✅
ux-option ✅

🏗️ Correct Architecture (What It Should Be)

Design Principle

Embeddables (ui-core, ui-forms)
    ↓ used by
Widgets (libs-widgets)
    ↓ used in
Editor/Canvas

Library Responsibilities

1. ui-core (Pure Embeddables)

Purpose: Reusable UI components with NO widget logic

Should contain:

ui-button ✅ (embeddable button)
ui-card ✅ (embeddable card)
ui-input ✅ (embeddable input)
ui-icon ✅ (embeddable icon)
ui-tabs ✅ (embeddable tabs)
etc.

Should NOT contain: Widget lifecycle, BaseWidgetComponent, property groups

2. ui-forms (Form Embeddables)

Purpose: Form-specific reusable components

Should contain:

checkbox ✅
toggle ✅
select ✅
multi-select ✅
color-picker ✅
form-field ✅

Should NOT contain: Widget wrappers

3. libs-widgets/widgets (Full Widgets)

Purpose: Editor-aware widgets that extend BaseWidgetComponent

Should contain:

button-widget ✅ (wraps ui-button)
card-widget ✅ (wraps ui-card)
input-widget ✅ (wraps ui-input)
checkbox-widget ✅ (wraps ui-forms/checkbox)
text-widget ✅
image-widget ✅
etc.

Should: Use embeddables from ui-core and ui-forms, add widget logic

⚠️ Current Issues

Issue 1: Duplicate Implementation

Problem: Same component logic exists in multiple places

Example:

libs-widgets/widgets/src/lib/components/icon-widget/
libs-ui-core/ui-core/src/lib/components/icon/

Both implement icon rendering - which is correct?

Issue 2: Unclear Separation

Problem: No clear rule about what goes where

Questions:

Should breadcrumb be in widgets or ui-core?
Should context-menu be in widgets or ui-core?
Should editable-slug be in widgets or ui-core?

Issue 3: Maintenance Burden

Problem: Changes must be made in multiple places

Example: Fix a bug in chip → Must fix in:

libs-widgets/widgets/chip/
libs-ui-core/ui-core/chip/

❌ Violates DRY principle

Issue 4: Bundle Size

Problem: Same code shipped multiple times

Impact: Larger bundle, slower loads

💡 Recommended Consolidation Strategy

Phase 1: Categorize (Define Source of Truth)

For each duplicate, decide:

Option A: Embeddable Only (Keep in ui-core/ui-forms)

Component is pure UI, no widget logic
Used across multiple contexts (not just editor)
Examples: icon, breadcrumb, context-menu

Option B: Widget Only (Keep in libs-widgets)

Component is editor-specific
Needs BaseWidgetComponent lifecycle
Has property groups and variants
Examples: Probably none - all widgets should use embeddables!

Option C: Both (Embeddable + Widget Wrapper)

Embeddable in ui-core (pure component)
Widget wrapper in libs-widgets (adds editor logic)
Example: button (ui-button + button-widget) ✅ THIS IS CORRECT!

Phase 2: Consolidation Rules

Rule 1: UI Components → ui-core

Move to ui-core (keep as embeddables):

✅ breadcrumb
✅ chip
✅ chip-list
✅ clipboard
✅ context-menu
✅ editable-slug
✅ icon/icons
✅ input (ui-input)
✅ module-dock-slot
✅ simple-tabs
✅ ux-tabs

Delete from libs-widgets/widgets: Duplicate implementations

Rule 2: Form Components → ui-forms

Move to ui-forms (keep as embeddables):

✅ checkbox
✅ select (ux-select)

Delete from libs-widgets/widgets: Duplicate implementations

Rule 3: Widgets → Use Embeddables

Refactor widgets to use embeddables:

// ❌ BEFORE: Widget implements everything
@Component({
  selector: 'lib-icon-widget',
  template: `
    <i class="material-icons">{{ icon }}</i>
  `
})
export class IconWidgetComponent { }

// ✅ AFTER: Widget uses embeddable
@Component({
  selector: 'lib-icon-widget',
  template: `
    <ui-icon [icon]="config().icon" [customStyles]="customStyles()"></ui-icon>
  `
})
export class IconWidgetComponent extends BaseWidgetComponent { }

Phase 3: Implementation Plan

Step 1: Audit (Which implementation to keep?)

For each duplicate:

Compare implementations (ui-core vs widgets)
Choose most robust/feature-complete
Document decision

Step 2: Migrate (Move logic to embeddables)

Keep embeddable in ui-core/ui-forms
Refactor widget to use embeddable
Add widget-specific logic (properties, variants)
Test thoroughly

Step 3: Delete (Remove duplicates)

Delete duplicate from widgets/
Update imports across codebase
Update barrel exports
Verify no broken references

Step 4: Document (Prevent future duplication)

Update AGENTS.md with clear rules
Add linting rules (if possible)
Document architecture decisions

🎯 Specific Consolidation Examples

Example 1: Icon Component

Current State ❌

libs-widgets/widgets/src/lib/components/icon-widget/
├── icon-widget.component.ts (widget implementation)
├── icon-widget-property-groups.ts
└── index.ts

libs-ui-core/ui-core/src/lib/components/icon/
├── icon.component.ts (embeddable implementation)
└── index.ts

Desired State ✅

libs-ui-core/ui-core/src/lib/components/icon/
├── icon.component.ts (embeddable - pure UI)
└── index.ts

libs-widgets/widgets/src/lib/components/icon-widget/
├── icon-widget.component.ts (widget - uses <ui-icon>)
├── icon-widget-property-groups.ts
└── index.ts

Implementation

// icon-widget.component.ts
import { UiIconComponent } from '@libs-ui-core/ui-core';

@Component({
  selector: 'lib-icon-widget',
  imports: [UiIconComponent],
  template: `
    <ui-icon 
      [icon]="config().icon"
      [size]="config().size"
      [color]="config().color"
      [customStyles]="customStyles()"
    ></ui-icon>
  `
})
export class IconWidgetComponent extends BaseWidgetComponent {
  config = computed(() => ({...}));
  customStyles = computed(() => ({...}));
}

Example 2: Input Component

Current State ❌

libs-widgets/widgets/src/lib/components/input-widget/
└── input-widget.component.ts (full implementation)

libs-ui-core/ui-core/src/lib/components/input/
└── ui-input.component.ts (full implementation)

Desired State ✅

libs-ui-core/ui-core/src/lib/components/input/
└── ui-input.component.ts (embeddable - pure input)

libs-widgets/widgets/src/lib/components/input-widget/
└── input-widget.component.ts (widget - uses <ui-input>)

Example 3: Card Component

Current State ❌

libs-widgets/widgets/src/lib/components/card-widget/
└── card-widget.component.ts (full implementation)

libs-ui-core/ui-core/src/lib/components/card/
├── card.component.ts (full implementation)
├── card-header.component.ts
├── card-content.component.ts
└── card-footer.component.ts

Desired State ✅

libs-ui-core/ui-core/src/lib/components/card/
├── card.component.ts (embeddable - pure card UI)
├── card-header.component.ts
├── card-content.component.ts
└── card-footer.component.ts

libs-widgets/widgets/src/lib/components/card-widget/
└── card-widget.component.ts (widget - uses <ui-card>)

CardWidget should use <ui-card> embeddable!

🔥 Impact of Consolidation

Before ❌

14+ duplicate components
Inconsistent implementations
Changes need multiple updates
Larger bundle size
Confusion about which to use

After ✅

ONE source of truth per component
Consistent implementations
Change once, applies everywhere
Smaller bundle size
Clear architecture (embeddable vs widget)

📊 Estimated Effort

Phase	Components	Effort	Impact
Audit	14 duplicates	1 hour	Understand current state
Migrate High Priority	5 components	3-4 hours	Button, Card, Input, Icon, Checkbox
Migrate Medium Priority	5 components	2-3 hours	Tabs, Chip, Select, Context Menu
Migrate Low Priority	4 components	1-2 hours	Breadcrumb, Clipboard, Editable Slug, Module Dock
Testing & Cleanup	All	2 hours	Verify, delete duplicates, update docs
TOTAL	14 duplicates	9-12 hours	Clean architecture

🎯 Recommended Approach

Option 1: Aggressive Consolidation (Recommended ⭐)

Timeline: 2-3 days
Risk: Medium
Reward: Clean architecture

Steps:

Audit all 14 duplicates (1 hour)
Keep embeddables in ui-core/ui-forms as source of truth
Refactor widgets to use embeddables (like ButtonWidget does)
Delete duplicates from widgets/
Test thoroughly
Document architecture

Result: Clear separation, no duplication, smaller bundle

Option 2: Gradual Consolidation

Timeline: 1-2 weeks
Risk: Low
Reward: Medium

Steps:

Mark duplicates with deprecation warnings
Create migration guide for each
Gradually migrate over time
Delete when all usages updated

Result: Safer, but slower

Option 3: Live with Duplication (NOT Recommended ❌)

Timeline: 0 (no action)
Risk: None
Reward: None

Consequence: Technical debt grows, bundle size increases, maintenance harder

💡 My Strong Recommendation

Do Option 1: Aggressive Consolidation NOW

Why?

You're in active development - no backward compatibility needed
Patterns are clear - ButtonWidget shows the way
Momentum is high - we just fixed all sizing issues
Foundation is solid - unified property system ready
Technical debt is young - easier to fix now than later

Plus, you said: "condensce the similar or same widgets" - you WANT this done!

🚀 Proposed Consolidation Order

Priority 1: Most Impactful (Start Here!)

card-widget → Use <ui-card> embeddable
input-widget → Use <ui-input> embeddable
checkbox-widget → Use <ui-checkbox> embeddable from ui-forms
select-widget → Use <ux-select> embeddable from ui-forms

Why: High usage, clear embeddable pattern, immediate benefit

Priority 2: Medium Impact

icon-widget → Use <ui-icon> embeddable
simple-tabs → Use <simple-tabs> embeddable (or consolidate into ux-tabs)
ux-tabs → Keep embeddable, remove widget duplicate
chip-widget → Use <ui-chip> embeddable
context-menu → Keep embeddable in ui-core, delete from widgets

Priority 3: Lower Impact

breadcrumb → Likely keep in ui-core only (not typically a widget)
clipboard → Likely keep in ui-core only (utility component)
editable-slug → Keep in ui-core only (specialized input)
module-dock-slot → Keep in ui-core only (layout component)

📝 Consolidation Checklist

For EACH duplicate:

Step 1: Audit

Which version is more feature-complete?
Which is more recently updated?
Which follows our patterns better?
Are there any breaking changes?

Step 2: Choose Source of Truth

Keep embeddable in ui-core/ui-forms
Mark as source of truth
Document decision

Step 3: Refactor Widget (if needed)

Import embeddable
Use embeddable in template
Add widget logic (BaseWidgetComponent, properties)
Pass customStyles to embeddable

Step 4: Delete Duplicate

Remove duplicate from other library
Update all imports across codebase
Update barrel exports
Verify compilation

Step 5: Test

Component renders correctly
Properties panel works
No visual regressions
Bundle size reduced

🎊 Expected Outcomes

After consolidation:

Code Quality ✅

✅ DRY principle enforced
✅ Clear architecture (embeddable vs widget)
✅ Easier maintenance
✅ Fewer bugs (one source of truth)

Bundle Size ✅

✅ ~10-15% reduction (estimated)
✅ Faster initial load
✅ Better code splitting
✅ Smaller lazy chunks

Developer Experience ✅

✅ Clear where to add new components
✅ Obvious how to create new widgets
✅ Easy to find and fix bugs
✅ AI-trainable patterns

🔥 The Bottom Line

Current State: 🚨 14 duplicate components
Goal: 🎯 Zero duplication, clear architecture
Effort: 9-12 hours over 2-3 days
Reward: ♾️ Clean codebase, easy maintenance, smaller bundle

Recommendation: DO IT NOW while momentum is high!

🎯 What Do You Want?

Option A: FULL CONSOLIDATION (Aggressive)

✅ Fix all 14 duplicates
✅ Clean architecture
⏰ 9-12 hours

Option B: TOP 5 ONLY (Balanced)

✅ Fix most impactful (card, input, checkbox, select, icon)
⏰ 3-4 hours

Option C: DOCUMENT ONLY (Passive)

📚 Document the issue, fix later
⏰ 30 minutes

Status: 📋 Analysis complete
Decision: Awaiting your call
Ready: To execute immediately

Let me know which option you prefer! 🚀

🔍 Widget/Embeddable Duplication Analysis

🎯 The Problem

📊 Duplicate Components Found

Category 1: UI Components (12 duplicates)

Category 2: Form Components (2 duplicates)

Category 3: Unique to libs-widgets (Clean ✅)

Category 4: Unique to ui-core (Embeddables ✅)

Category 5: Unique to ui-forms (Form Embeddables ✅)

🏗️ Correct Architecture (What It Should Be)

Design Principle

Library Responsibilities

1. ui-core (Pure Embeddables)

2. ui-forms (Form Embeddables)

3. libs-widgets/widgets (Full Widgets)

⚠️ Current Issues

Issue 1: Duplicate Implementation

Issue 2: Unclear Separation

Issue 3: Maintenance Burden

Issue 4: Bundle Size

💡 Recommended Consolidation Strategy

Phase 1: Categorize (Define Source of Truth)

Phase 2: Consolidation Rules

Rule 1: UI Components → ui-core

Rule 2: Form Components → ui-forms

Rule 3: Widgets → Use Embeddables

Phase 3: Implementation Plan

Step 1: Audit (Which implementation to keep?)

Step 2: Migrate (Move logic to embeddables)

Step 3: Delete (Remove duplicates)

Step 4: Document (Prevent future duplication)

🎯 Specific Consolidation Examples

Example 1: Icon Component

Current State ❌

Desired State ✅

Implementation

Example 2: Input Component

Current State ❌

Desired State ✅

Example 3: Card Component

Current State ❌

Desired State ✅

🔥 Impact of Consolidation

Before ❌

After ✅

📊 Estimated Effort

🎯 Recommended Approach

Option 1: Aggressive Consolidation (Recommended ⭐)

Option 2: Gradual Consolidation

Option 3: Live with Duplication (NOT Recommended ❌)

💡 My Strong Recommendation

Do Option 1: Aggressive Consolidation NOW

🚀 Proposed Consolidation Order

Priority 1: Most Impactful (Start Here!)

Priority 2: Medium Impact

Priority 3: Lower Impact

📝 Consolidation Checklist

Step 1: Audit

Step 2: Choose Source of Truth

Step 3: Refactor Widget (if needed)

Step 4: Delete Duplicate

Step 5: Test

🎊 Expected Outcomes

Code Quality ✅

Bundle Size ✅

Developer Experience ✅

🔥 The Bottom Line

🎯 What Do You Want?

Option A: FULL CONSOLIDATION (Aggressive)

Option B: TOP 5 ONLY (Balanced)

Option C: DOCUMENT ONLY (Passive)