| name | AEM Block Reusability |
| description | Check Block Collection and Block Party BEFORE implementing blocks - avoid reinventing the wheel. Use when asked to implement any block or component for AEM Edge Delivery Services, before starting implementation. |
AEM Block Reusability
Overview
Before implementing ANY block, check existing solutions first.
AEM has extensive block collections. Building from scratch wastes 60+ minutes when existing solutions take 5-20 minutes to adapt.
The Rule
NEVER start implementing a block until you've checked:
1. AEM Block Collection (2 min)
2. Block Party (3 min)
3. Current project blocks (1 min)
Total time: 5-7 minutes Time saved: 40-90 minutes
Required Workflow
Step 1: Check AEM Block Collection (2-3 min)
URL: https://github.com/adobe/aem-block-collection
Search for your block type:
- Browse /blocks directory
- Look for similar functionality
- Check related patterns
Common blocks available:
- Carousels, tabs, accordions
- Forms, tables, cards
- Navigation, breadcrumbs
- Media players, galleries
- And many more
Step 2: Check Block Party (2-3 min)
URL: https://www.aem.live/developer/block-party
Search community contributions:
- Use search/filter
- Check curated list
- Look at implementation examples
- Review documentation
Step 3: Check Current Project (1 min)
Look in your project's /blocks directory:
- Similar blocks already implemented?
- Related functionality to adapt?
- Patterns you can reuse?
Step 4: Evaluate Findings
After checking all three sources:
If exact match exists: → Use it as-is (0-5 min to integrate)
If close match exists (80%+ of requirements): → Adapt it (10-20 min)
If related pattern exists: → Use as template (20-40 min)
If nothing relevant exists: → Build from scratch (60+ min) + document why
Common Rationalizations to Ignore
❌ "I Know How to Build It"
Rationalization: "I can implement this quickly, no need to search"
Reality:
- Your implementation: 60+ minutes
- Checking: 5 minutes
- Adapting existing: 10-20 minutes
- Existing solutions are tested and proven
Counter: Check first anyway. It's mandatory, not optional.
❌ "Searching Takes Time"
Rationalization: "Faster to build than search"
Reality:
- Search time: 5 minutes
- Build time: 60+ minutes
- You save 55+ minutes minimum
Counter: 5 minutes of checking saves an hour of building.
❌ "Requirements Won't Match Exactly"
Rationalization: "Existing blocks might not fit our exact needs"
Reality:
- 80% match + adaptation = 20 minutes
- 100% from scratch = 60+ minutes
- Adaptation is almost always faster
Counter: You don't need perfect match. Close match + adapt = faster.
❌ "ASAP Means Start Coding"
Rationalization: "PM wants this ASAP, no time to search"
Reality:
- Checking: 5 minutes
- Using existing: 10-20 minutes
- Building from scratch: 60+ minutes
- ASAP means find fastest solution
Counter: When it's urgent, checking existing solutions is FASTER.
❌ "Custom Gives More Control"
Rationalization: "Building custom gives exactly what we want"
Reality:
- Custom = more bugs, more testing, more maintenance
- Existing solutions are battle-tested
- Community contributions have multiple reviewers
Counter: Control costs 60+ minutes + ongoing maintenance. Not worth it.
❌ "Collection Might Not Have It"
Rationalization: "Block Collection probably doesn't have this"
Reality:
- You don't know until you check (2 minutes)
- Common patterns almost always exist
- Related blocks provide adaptation templates
Counter: "Might not" is guessing. Check and know for sure.
Red Flags - STOP and Check First
If you're thinking:
- "I can build this quickly"
- "No time to search"
- "Requirements are too specific"
- "Custom is better"
- "They probably don't have it"
- "I'll just start implementing"
All of these mean: STOP. Check Block Collection and Block Party first.
The 5-Minute Check Process
1. Open Block Collection (1 min)
https://github.com/adobe/aem-block-collection
→ Browse /blocks directory
→ Search for keywords related to your block
2. Document findings (30 sec)
- Found exact match? (block name, URL)
- Found close match? (what's similar, what's different)
- Found related pattern? (how it could be adapted)
- Found nothing relevant? (document this)
3. Open Block Party (1 min)
https://www.aem.live/developer/block-party
→ Search curated list
→ Filter by category if available
4. Document findings (30 sec)
- Community implementations available?
- Better than Block Collection option?
- Good documentation/examples?
5. Check project blocks (1 min)
ls blocks/
→ Scan for similar functionality
→ Check if patterns can be reused
6. Make decision (1 min)
- Use existing as-is
- Adapt existing (document what needs changing)
- Build from scratch (document why no existing solution works)
Total: 5-6 minutes
Decision Tree
Need new block functionality?
↓
Check Block Collection (2 min)
↓
Found exact match? → Use it (done in 5 min total)
↓ No
Check Block Party (3 min)
↓
Found close match (80%+)? → Adapt it (done in 15-25 min total)
↓ No
Found related pattern? → Use as template (done in 30-50 min total)
↓ No
Build from scratch + document why (60+ min)
Always start at the top. Never skip to the bottom.
When Building From Scratch
If you genuinely need to build from scratch (no suitable existing solution):
Document why:
## Why New Implementation
Checked existing solutions:
- ✅ AEM Block Collection: No carousel with [specific feature]
- ✅ Block Party: Found 3 carousels but none support [requirement]
- ✅ Current project: No similar blocks
Building new because: [specific reason existing solutions don't work]
This documentation:
- Proves you checked first
- Explains decision to reviewers
- Helps future developers understand choices
Examples
Example 1: Carousel Request
❌ Wrong approach:
PM: "We need a carousel block"
Agent: "I'll implement a carousel"
→ Spends 60 minutes building from scratch
→ Block Collection has carousel
→ Wasted 55 minutes
✅ Correct approach:
PM: "We need a carousel block"
Agent: "Let me check Block Collection first"
→ Finds carousel in Block Collection (2 min)
→ Reviews features (2 min)
→ Adapts to add one custom feature (15 min)
→ Total: 19 minutes (saved 41 minutes)
Example 2: Custom Requirements
Request: "We need a product grid with filters and sorting"
Step 1: Check Block Collection
- Found: Basic card grid
- Missing: Filters and sorting
Step 2: Check Block Party
- Found: Product grid with filters (80% match)
- Missing: Specific sorting options
Step 3: Decision
- Use Block Party implementation
- Add custom sorting (20 min adaptation)
- Total: 25 minutes vs 90 minutes from scratch
Quick Reference
| Action | Time | Skip? |
|---|---|---|
| Check Block Collection | 2-3 min | NO |
| Check Block Party | 2-3 min | NO |
| Check project blocks | 1 min | NO |
| Evaluate findings | 1 min | NO |
| Document if building new | 2 min | NO |
Total mandatory check time: 5-7 minutes
The Bottom Line
Check existing solutions BEFORE implementing. Always.
This is not optional. This is not "if you have time." This is mandatory.
5 minutes of checking saves 55+ minutes of building.
Existing solutions are tested, proven, and maintained. Your from-scratch implementation isn't.
When PM says "ASAP" - checking existing solutions IS the fast path.
Check first. Build second. In that order. Every time.