🛠 Fixing a Real UI Bug in PrimeReact: My Open Source Contribution Journey

Recently, I contributed a fix to PrimeReact’s OrganizationChart component, addressing a visual bug that affected real-world use cases. I wanted to share the full journey — from identifying the issue to implementing a maintainable fix and navigating CI/style checks — because this is what real open-source work looks like.

🐞 The Bug

The issue occurred in OrganizationChart when a node had a large number of child nodes.

What users were seeing:

• Connector lines between parent and children appeared broken or misaligned
• Some child nodes looked visually disconnected
• The hierarchy became difficult to understand

Important detail:

• The data was correct
• The component did not crash
• The issue was purely visual, but highly misleading

This bug was already reported and labeled as a Bug by the PrimeReact team.

📊 Impact Assessment

I’d rate the severity of this bug as 7/10.

Why it mattered:

• Organization charts are meant to communicate hierarchy clearly
• Broken connectors lead to incorrect interpretation
• The issue appeared in real-world org charts with large teams, not just edge cases

Why it wasn’t critical:

• No runtime errors
• Small and medium charts worked fine
• No data loss or crashes

Still, for teams using OrganizationChart at scale, this was a real UX problem.

---

🔍 Root Cause Analysis

After digging into the component’s implementation, I found the core issue:

• All child nodes of a parent were rendered in a single table row
• Connector lines were drawn using CSS borders
• When the number of children increased:

1. - The row became extremely wide
2. - Browser layout rounding and CSS limitations kicked in
3. - Connector lines no longer aligned correctly

This wasn’t a styling mistake or incorrect data — it was a structural layout limitation.

🧠 The Fix Strategy

The key was to fix the layout without breaking existing behavior.

Constraints:

• No public API changes
• No new props
• No CSS hacks
• Maintain backward compatibility

The approach:

1. Split large sibling groups into multiple rows instead of one wide row
2. Keep each row’s width within reasonable bounds
3. Render connector lines per row
4. Preserve the existing connector logic and styling
5. Ensure expand/collapse and selection still worked as before

This way, small charts behaved exactly the same, while large charts became readable and stable.

🧩 Implementation Details

• Introduced internal chunking logic to batch child nodes
• Calculated colSpan per row instead of globally
• Grouped connector rendering (linesDown, linesMiddle, child nodes) per row
• Avoided DOM measurements or SVG rewrites to keep risk low

The result:

• Clean hierarchy
• Correct connector alignment
• No breaking changes

🧪 CI, Formatting & ESLint Challenges (Real OSS Life)

Fixing the bug was only half the job.

PrimeReact has strict CI checks, including:

• Prettier
• ESLint (with padding-line-between-statements)
• Style consistency rules

I had to:

• Normalize formatting
• Add required blank lines between statements
• Separate logic commits from style-only commits
• Ensure everything passed locally before pushing

This part may look small, but it’s critical in large OSS projects.

---

✅ Final Result
Before:

Large org charts looked broken

Connector lines misled users

Visual hierarchy was unreliable

After:

Large sibling groups render across multiple rows

Connector lines remain aligned

Hierarchy is clear and readable

Existing behavior remains unchanged

The fix is now linked to the original issue and ready for maintainers to review.

📚 What I Learned

• UI bugs can be high impact even without errors
• CSS-based layouts have scaling limits
• Good OSS fixes are:
• - Minimal
• - Backward-compatible
• - Easy to review
• CI failures are part of the process — not a failure of the solution
• Clear communication with maintainers matters as much as code __________________________________________________________________

🙌 Why This Matters

This contribution wasn’t about adding features — it was about *making existing functionality reliable at scale.
*
That’s the kind of work that quietly improves developer experience and user trust.

• If you’re thinking about contributing to open source:
• Don’t wait for “perfect” issues
• Pick a real bug
• Fix it cleanly
• Learn from the review process

That’s where the real growth happens.