🐛 Bug: React anti-pattern - Array index used as key in ToolingTable

[Sam-61s]

Describe the bug

In pages/tools/components/ToolingTable.tsx (line 188), array index is being used as the key prop for mapped <tr> elements. This is a React anti-pattern that can cause rendering issues, incorrect component updates, and bugs when the list is modified (sorted, filtered, or items are added/removed).

Using array indices as keys is problematic because:

• Indices are not stable across re-renders when items are reordered, filtered, or removed
• Can cause React to incorrectly reuse component instances
• May lead to stale state and incorrect UI updates
• Negatively impacts performance and reconciliation

Steps To Reproduce

1. Navigate to the /tools page
2. Open browser DevTools and observe the React component tree
3. Apply filters or sorting to the tools table
4. Observe that components may not update correctly due to index-based keys
5. In the code, check pages/tools/components/ToolingTable.tsx line 188
6. Note the use of index as the key prop in the .map() function

Expected Behavior

The key prop should use a unique, stable identifier from the tool object itself instead of the array index.

Recommended fix:
{toolsByGroup[group].map((tool: JSONSchemaTool) => {
const toolKey = tool.source || tool.name || tool.url;
return (
// ✅ Using stable, unique identifier
...

);
})}

This ensures:

• Stable keys that persist across re-renders
• Correct component reconciliation
• Better performance
• Predictable behavior when sorting/filtering

Screenshots

No response

Device Information [optional]

- OS:
- Browser:
- version:

Are you working on this issue?

Yes

Do you think this work might require an [Architectural Decision Record (ADR)]? (significant or noteworthy)

No

[Sam-61s]

hey @Utkarsh-123github
i would like to work on this please assign this issue to me🙏

[Shuklax]

I noticed this is a very valid React anti-pattern that affects both performance and UI stability during filtering/sorting.

I've submitted a PR (#2031 ) that implements a robust fix for this. Instead of a simple name-based key, I used a composite stable key (name + source/homepage) to ensure uniqueness even in edge cases. I also ensured the fix is applied to both the Desktop and Mobile versions of the table.

Hopefully, this helps move the project forward!

[Sam-61s]

Hi @Shuklax , thanks for the effort and for submitting the PR 👍

Just a quick note on the process: this repo follows a strict contributing guideline where issues should be assigned by a maintainer before opening a PR. I had already fixed this issue locally and was waiting to open a PR once it got assigned to me.

It might be helpful to check the CONTRIBUTING.md and contribution workflow before submitting PRs. Thanks for understanding 🙌

[Utkarsh-123github]

Hi @Sam-61s this is a good point, please go ahead with your PR.
Thanks!