DEV Community: Rohan Satkar | Coderxrohan

My First Feature Contribution to Open Source: A Learning Journey with GitLab

Rohan Satkar | Coderxrohan — Wed, 28 Jan 2026 17:24:06 +0000

Contributing a feature to a large open-source project for the first time is both exciting and intimidating—and recently, I had the opportunity to experience exactly that. My merge request !3074, which adds support for parsing absolute SSH remote URLs in the GitLab VS Code extension, was merged into main, marking my first feature-level contribution to a widely used open-source tool.

When I started exploring the issue, I didn’t initially set out to “build a feature.” I was browsing open issues to understand how real production bugs are identified and handled in mature projects. That’s when I came across a report explaining that SSH remotes formatted like

git@gitlab.com:/group/project.git

were not being recognized correctly.
On the surface, this looked like a minor parsing issue—but digging deeper revealed why it mattered.

The colon-slash (:/) syntax represents an absolute path on the remote server, and while it’s a valid SSH format, the existing logic didn’t account for it. This meant that for some users, the GitLab VS Code extension couldn’t correctly identify or link their repositories. It was a small gap, but one that directly affected user experience.

My first learning moment came from understanding the existing codebase. I spent time reading through the SSH normalization logic, understanding the different regex patterns already in use, and seeing how small ordering decisions could have big consequences. One key realization was that the fix wasn’t just about adding a new pattern—it had to be placed before the general SSH path matcher to avoid incorrect matches. That insight alone taught me how careful and intentional maintainers need to be when working with parsing logic.

Implementing the fix itself was straightforward, but doing it the right way took thought. I added a dedicated regex to detect absolute SSH paths and normalized them to a standard ssh:// format so downstream parsing would work consistently. More importantly, I backed the change with unit tests—something I’ve learned is non-negotiable in serious open-source projects. Writing tests for both simple and nested group paths helped me understand how edge cases are treated as first-class citizens in production code.

The review process was another major learning experience. Maintainers and reviewers provided clear, supportive feedback, and the overall tone was collaborative rather than intimidating. Seeing all threads resolved, tests passing, and the merge train succeed reinforced how much process and trust goes into every change—no matter how small it looks from the outside.

What stood out to me most was how focused the contribution needed to be. This wasn’t about adding new functionality for its own sake, but about fixing a specific user-facing issue without introducing regressions or breaking changes. That mindset—solve one problem well—has reshaped how I now think about open-source contributions.

Having this merge request included as part of the January 2026 GitLab Hackathon makes the experience even more meaningful. It validated not just the code, but the effort to understand the problem deeply, communicate clearly, and follow project standards.

This contribution gave me confidence that I can meaningfully participate in large open-source ecosystems. More importantly, it taught me that impactful contributions don’t always require massive features—sometimes, they come from noticing a small gap and taking the time to fix it properly.

This is just the beginning of my open-source journey, and I’m excited to keep learning, contributing, and giving back to the community that builds the tools we all rely on every day.

My successfully merged PRs:

"I'm proud to have earned the Level 2 Contributor badge from the GitLab community. It reflects the time and effort I've put into meaningful contributions, and it's motivating to see that impact recognized. Being part of an open-source ecosystem where collaboration drives innovation is incredibly rewarding, and this milestone pushes me to keep learning and giving back."

Official Page

https://contributors.gitlab.com/hackathon

Profile:

https://gitlab.com/Coderxrohan

🧠 The React Bug That Only Appears When Your Code Is Too Fast

Rohan Satkar | Coderxrohan — Thu, 01 Jan 2026 18:07:32 +0000

While working with PrimeReact’s DataTable, I ran into a bug that nearly broke my brain.

Buttons inside table rows were logging different state values, even though the state was global and clearly up to date.

At first glance, it looked like:

a React Hook Form issue
or a state sync problem
or even a React bug

It turned out to be none of those.

This post walks through:

the exact problem
why it was so confusing
how I isolated the root cause
and how a one-line fix resolved it without sacrificing performance ________________________________________________________

🧩 The Problem: “Why does each row see a different state?”

I had a DataTable where each row had a button.

Clicking the buttons produced this output:

Button 0 clicked → items.length = 1 Button 1 clicked → items.length = 2 Button 2 clicked → items.length = 3

But this made no sense.

At the time of clicking:

the global state clearly had 3 items

every button should have logged 3

Instead, each button behaved as if it remembered an older version of state.

🔬 Reproducing the Issue

Steps to reproduce:

Add 3 rows to the table
Click the button in row 1 → logs 1
Click row 2 → logs 2
Click row 3 → logs 3

Each row was somehow “stuck” in the past.

🤔 Why This Was So Confusing

Here’s what made this bug especially sneaky:

The UI looked correct
State updates were working
No errors, no warnings
Disabling memoization (cellMemo={false}) “fixed” it

That last part was the clue.

🧠 The Hidden Culprit: Memoization + Closures

PrimeReact’s DataTable uses cell memoization (cellMemo=true by default) to improve performance.

That means:

Cells do not re-render
unless specific memo keys change

What went wrong?

Existing rows kept the same object reference
Memoized cells were not re-rendered
Event handlers (onClick) kept the closure from the render they were created in

So each button captured a snapshot of state at creation time.

This is classic stale closure behavior — but caused by memoization, not state logic.

🧪 Minimal Reproduction (Pure React)

I recreated the exact same bug with React.memo:

const Row = React.memo(
  ({ item, index, snapshotLength }) => {
    const onClick = () => {
      console.log(index, snapshotLength);
    };
    return <button onClick={onClick}>Click</button>;
  },
  (prev, next) => prev.item === next.item // ❌ ignores snapshotLength
);

Because snapshotLength was ignored:

the row never re-rendered

the click handler kept stale data

This was the exact same failure mode as DataTable’s cellMemo.

🛠️ The Actual Fix (Not the Hack)

The easy workaround was:

<DataTable cellMemo={false} />

But that:

disables performance optimizations
hurts large tables

The real fix

The memoization key needed to change when row structure changed.

In PrimeReact, the fix was simple:

Before

cellMemoProps = { index }

After

cellMemoProps = { rowIndex }

Why this works:

rowIndex changes when rows are added/removed/reordered
Memoized cells now re-render when they should
Fresh closures, same performance benefits

✅ Result

After the fix:

Button 0 → items.length = 3
Button 1 → items.length = 3
Button 2 → items.length = 3

No stale closures.
No performance regression.
No API changes. ________________________________________________________

🤯 Bonus Insight: Why useFieldArray “Just Worked”

One interesting discovery:

When using React Hook Form’s useFieldArray, this bug never appeared.

Why?

Because useFieldArray:

creates new object references on updates

naturally invalidates memoization

So rows re-render automatically.

It wasn’t magic — just object identity working in your favor.

🧠 Key Takeaways

Memoization bugs are identity bugs, not state bugs
If a prop affects behavior, it must participate in memo invalidation
Stale closures can exist even when state is correct
Disabling memoization is a workaround, not a solution
Performance optimizations demand extra correctness discipline

🚀 Final Thoughts

This was one of those bugs that:

looks impossible
survives logging
disappears when you “simplify” things

But once you think in render snapshots, everything clicks.

Huge thanks to the PrimeReact maintainers for quick feedback and collaboration — and to the original reporter for the excellent reproduction.

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

Rohan Satkar | Coderxrohan — Wed, 31 Dec 2025 20:52:51 +0000

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:

- The row became extremely wide
- Browser layout rounding and CSS limitations kicked in
- 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:

Split large sibling groups into multiple rows instead of one wide row
Keep each row’s width within reasonable bounds
Render connector lines per row
Preserve the existing connector logic and styling
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.

Fixing Focus Management in PrimeReact Calendar (Open Source Contribution)

Rohan Satkar | Coderxrohan — Mon, 22 Dec 2025 15:03:20 +0000

Open-source contributions don’t always mean adding big features. Sometimes, the most impactful changes are small UX fixes that improve how thousands of users interact with a component every day.

This post walks through a usability issue I fixed in the Calendar component of PrimeReact, and how a minimal, targeted change improved user interaction without breaking accessibility.

Background

PrimeReact is a popular React UI component library used by 50k+ projects. Its Calendar component supports different selection modes:

single
range
multiple

Each mode has slightly different interaction expectations, especially around keyboard focus and accessibility.

The Problem

In single selection mode, the following behavior occurred:
User clicks the input → calendar opens
User selects a date
Calendar closes ✔️
Input field is immediately auto-focused ❌

Also Read: Youtube PIP Automation Extension

Because the input regained focus programmatically, clicking it again did not reopen the calendar. From a user’s perspective, the component felt broken.

This issue was reported and tracked in the PrimeReact repository.

Why This Matters

This wasn’t just a cosmetic issue:
It blocked normal mouse interaction
It created confusion for users

It behaved differently than expected for a single-selection date picker

At the same time, focus restoration is important for accessibility, especially in range and multiple selection modes. So the solution had to be careful — not just “remove focus handling”.

Root Cause

While tracing the code path after date selection, I found that the following function was being called unconditionally:

reFocusInputField();

This made sense for:

range selection
multiple selection

…but not for single selection, where the calendar overlay closes immediately.

The Fix

Instead of removing the logic entirely, I made it context-aware by checking the selection mode:

- reFocusInputField();
+ if (props.selectionMode !== 'single') {
+     reFocusInputField();
+ }

Result
Selection Mode Behavior After Fix
Single Calendar closes, no forced refocus, input clickable again
Range Refocus preserved
Multiple Refocus preserved

The fix:

Solved the reported issue
Preserved keyboard accessibility
Avoided regressions
Passed CI checks

Was reviewed and merged by PrimeReact maintainers

What I Learned

UX bugs often live in “working” code
Accessibility and usability need to be balanced, not traded off
Maintainers value small, well-scoped fixes
Explaining why a change is needed is as important as the change itself

Closing Thoughts

This contribution reinforced that meaningful open-source work doesn’t have to be large or complex. A few lines of carefully considered code can improve the experience of thousands of users.

If you’re looking to contribute to open source, fixing small usability issues is a great place to start.

Follow me on: