feat(gemini): An interactive React web application to visualize tracked wasteland resources on a dynamic map, aiding in scavenging and planning.

[polsala]

Implementation Summary

• Utility: nightly-resource-nexus-map
• Provider: gemini
• Location: react-webpage/nightly-nightly-resource-nexus-map
• Files Created: 9
• Description: An interactive React web application to visualize tracked wasteland resources on a dynamic map, aiding in scavenging and planning.

Rationale

• Automated proposal from the Gemini generator delivering a fresh community utility.
• This utility was generated using the gemini AI provider.

Why safe to merge

• Utility is isolated to react-webpage/nightly-nightly-resource-nexus-map.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at react-webpage/nightly-nightly-resource-nexus-map/README.md
• Run tests located in react-webpage/nightly-nightly-resource-nexus-map/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Component decomposition – The UI is nicely split into ResourceFilter, ResourceMap, and ResourceLegend. This keeps each piece focused and makes future extensions straightforward.
• State handling – The top‑level App component correctly lifts the filter state and passes it down as a prop, avoiding prop‑drilling beyond what’s needed.
• Mock‑first approach – All data lives in a hard‑coded mockResources array, which guarantees deterministic builds and offline testability.
• Styling – The CSS grid layout (though not shown in full) gives a clean, responsive map without pulling in heavyweight mapping libraries.
• README – The documentation includes a clear feature list, install/run instructions, and a “Mock Rationale” section that explains why the utility is self‑contained.

🧪 Tests

Area	Observation	Suggested improvement
Component rendering	Tests verify that titles, buttons, and legends appear.	Add explicit data-testid attributes (e.g., data-testid="resource-filter"). Then use screen.getByTestId instead of brittle role/class queries.
Filter interaction	fireEvent.click checks the active class on buttons.	Consider using userEvent from @testing-library/user-event for more realistic interaction (focus, keyboard navigation).
Map grid	screen.getAllByRole('generic', { className: 'map-cell' }) is not a supported query.	Give each cell a role="gridcell" or a data-testid="map-cell" and query with getAllByRole('gridcell') or getAllByTestId('map-cell').
Resource titles	Tests rely on title attributes like Water at (1, 3).	Ensure those titles are set in the component (<div title={...}>). If they are missing, add them; otherwise, consider using aria-label for better accessibility.
Coverage	Tests cover “All”, “Water”, “Food”, and an invalid filter.	Add a test for the “All” filter after a filter change to confirm the map resets correctly. Also test that the legend updates (if you ever make it dynamic).
Snapshot / visual regression	None present.	A lightweight snapshot test of the rendered map (or a visual regression test with jest-image-snapshot) can catch accidental UI regressions.

Example fix for the grid‑cell query

// In ResourceMap.jsx
<div
  key={cellId}
  role="gridcell"
  data-testid="map-cell"
  className="map-cell"
>
  {resource && <span title={`${resource.type} at (${resource.x}, ${resource.y})`}>{resource.symbol}</span>}
</div>

// In ResourceMap.test.js
const cells = screen.getAllByTestId('map-cell');
expect(cells).toHaveLength(100);

🔒 Security

• XSS surface – Resource symbols are emojis (e.g., 💧). While they are safe, any future change that allows user‑provided symbols or labels should be sanitized or rendered via React’s escaping (which is default). Add a comment reminding future contributors to avoid dangerouslySetInnerHTML.
• Dependency hygiene – The project pulls in react, react-dom, @testing-library/react, etc. Ensure the repository’s CI runs npm audit (or yarn audit) and that the lockfile is committed.
• Content‑Security‑Policy (CSP) – If this utility ever gets deployed to a public domain, consider adding a CSP header to block inline scripts/styles. The current static build is low‑risk, but a note in the README would be helpful for downstream users.

🧩 Docs / Developer Experience

• Path inconsistency – The README instructs users to cd react-webpage/nightly-resource-nexus-map, but the actual folder is react-webpage/nightly-nightly-resource-nexus-map. Align the path in the docs with the real directory name.

• Running tests – The “How to Test” section repeats the navigation step. You could combine the steps:

  cd react-webpage/nightly-nightly-resource-nexus-map && npm install && npm test

• Component API docs – Adding a short JSDoc comment (or PropTypes) for each component’s props (activeFilter, onFilterChange, filter) will help IDE autocomplete and future contributors.

• Accessibility checklist – Mention that buttons have discernible text, but consider adding aria-pressed to indicate the active filter state, and role="grid" on the map container.

• Live demo – Since the app is lightweight, a npm run build && serve -s build command (or a GitHub Pages link) would let reviewers quickly see the final UI without needing a dev server.

🧱 Mocks / Fakes

• Self‑contained mock data – The mockResources array lives inside ResourceMap.js, which is great for deterministic tests.

• Future extensibility – If you ever replace the mock with an API call, abstract the data source behind a hook (e.g., useResources) and provide a mock implementation for tests. This will keep the current test suite unchanged while allowing real data later.

• Test‑only overrides – Right now the tests rely on the hard‑coded data. If you add more resources, remember to update the test expectations accordingly, or switch to a data‑driven approach:

  // tests/ResourceMap.test.js
  const mockResources = [
    { id: 1, type: 'Water', x: 1, y: 3, symbol: '💧' },
    // …
  ];
  jest.mock('../src/components/ResourceMap', () => ({
    __esModule: true,
    default: (props) => <OriginalResourceMap {...props} resources={mockResources} />,
  }));

  This decouples the component from its internal mock and makes the test intent clearer.

---

Overall, the utility is a solid, self‑contained addition that delivers the promised interactive map. Addressing the minor test‑query issues, tightening the documentation path, and adding a few accessibility and type‑safety touches will make the contribution even more robust and maintainable. Happy coding!

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Component decomposition – App, ResourceFilter, ResourceMap, and ResourceLegend are each isolated in their own files, making the UI easy to reason about and extend.
• State handling – The filter state lives in App and is passed down as a simple prop, which keeps the data‑flow unidirectional and testable.
• Deterministic mock data – All resource locations are hard‑coded inside ResourceMap, guaranteeing that the UI behaves the same on every run and that the tests are repeatable.
• README – The README already contains a quick‑start guide, a feature list, and a “How to Test” section, which is a good baseline for a new utility.
• Basic test coverage – The test suite checks that the title renders, that filter buttons toggle the active state, and that the map updates when the filter changes.

---

🧪 Tests

Observation	Recommendation
screen.getAllByRole('generic', { className: 'map-cell' }) is not a valid query – getAllByRole cannot filter by className.	Use a test‑id or an accessible role/label. Example: jsx<br>// in ResourceMap.jsx<br<div data-testid="map-cell" className="map-cell" … /> Then in the test: js<br>const cells = screen.getAllByTestId('map-cell');<br>expect(cells).toHaveLength(100);
Tests assume resources that are not present in the truncated mockResources (e.g., “Meds at (3, 6)”, “Tools at (6, 9)”).	Verify the full mock array includes every resource referenced in the tests. If you add new resources, keep the test data in sync, or generate the expected titles programmatically from the mock array.
The filter‑change test checks for the presence/absence of titles but does not assert that the underlying grid updates (e.g., that the correct number of cells is rendered).	Add an assertion on the count of rendered resource icons after each filter change: js<br>expect(screen.getAllByTestId('resource-icon')).toHaveLength(expectedCount);
No snapshot or accessibility tests.	Consider adding a snapshot test for ResourceLegend and an axe‑core accessibility test for the whole page to catch missing ARIA attributes.
Re‑rendering the whole app in each test is fine for now, but as the component tree grows it can become noisy.	Extract a renderApp helper in a test-utils.js file that wraps render(<App />) and returns useful queries. This keeps the test files DRY.

---

🔒 Security

• No external network calls – The utility is fully self‑contained, which eliminates surface‑area for injection attacks.
• Symbol rendering – Resource symbols are plain Unicode emojis (💧, 🍎, etc.). While they are safe, ensure they are rendered as text (e.g., <span>{symbol}</span>) and not injected via dangerouslySetInnerHTML.
• Content‑Security‑Policy (CSP) – If this app will ever be deployed to a shared domain, add a CSP header that disallows inline scripts/styles (React already avoids inline scripts, but the generated index.css may contain inline style tags).
• XSS via titles – The title attribute is built from static mock data, but if you ever switch to user‑provided data, sanitize it before using it in title or aria-label.

---

🧩 Docs / Developer Experience

Issue	Fix / Improvement
Folder name mismatch – README tells users to cd react-webpage/nightly-resource-nexus-map while the actual folder is nightly‑nightly‑resource‑nexus‑map.	Rename the folder to match the README (or update the README). Consistency prevents “directory not found” errors for new contributors.
Missing npm scripts – The README mentions npm start and npm test, but the package.json (not shown) may not expose those scripts for this sub‑utility.	Add a package.json inside the utility folder with "scripts": { "start": "react-scripts start", "test": "react-scripts test --watchAll=false" }. Document these scripts in the README.
Component prop documentation – ResourceMap accepts a filter prop, but the README does not describe it.	Add a short “Component API” section: md<br>### ResourceMap Props<br>- **filter** (`string`): one of the resource types or `'All'`. Determines which icons are rendered.
Running lint/format – No mention of linting or Prettier.	Include a lint script (eslint src/**/*.js) and a note in the README about running npm run lint before committing.
Live demo – The utility is visual; a GIF or screenshot in the README would help reviewers quickly gauge the UI.	Add a small animated GIF showing filter toggling and the legend.
Accessibility note – The README does not mention keyboard navigation.	Document that filter buttons are regular <button> elements (focusable by default) and that each resource cell has a title attribute for screen readers. Consider adding aria-label for better support.

---

🧱 Mocks / Fakes

• Hard‑coded mock data works for a demo, but keeping the data inside ResourceMap.js makes it harder to update or reuse.

  • Suggestion: Extract mockResources into a separate module (src/data/mockResources.js) and export it. Then ResourceMap can import the array, and tests can import the same source to generate expectations dynamically.
  • Benefit: Future contributors can add new resource types without touching component logic, and you can later replace the mock with a real API call while keeping the component API unchanged.

• Injectable data – For better testability and future extensibility, allow ResourceMap to accept an optional resources prop (defaulting to the internal mock).

  function ResourceMap({ filter, resources = mockResources }) {
    // filter logic …
  }
  ResourceMap.propTypes = {
    filter: PropTypes.string.isRequired,
    resources: PropTypes.arrayOf(
      PropTypes.shape({
        id: PropTypes.number.isRequired,
        type: PropTypes.string.isRequired,
        x: PropTypes.number.isRequired,
        y: PropTypes.number.isRequired,
        symbol: PropTypes.string.isRequired,
      })
    ),
  };

  This makes it trivial to unit‑test with a custom dataset and paves the way for a future backend integration.

---

TL;DR Action items

1. Rename folder or update README so the path is consistent.
2. Fix the broken import/JSX in ResourceMap.js (the diff was truncated; ensure the file ends with a proper export).
3. Adjust tests to use data-testid (or a proper role) instead of the invalid getAllByRole call.
4. Synchronize mock data with the expectations in the test suite (add missing resources or adjust tests).
5. Add PropTypes (or TypeScript) for component props and document them in the README.
6. Extract mock data to its own module and make it injectable.
7. Add a lint script and mention it in the docs.
8. Consider accessibility improvements (ARIA labels, keyboard focus) and optionally add an axe test.

These tweaks will tighten the codebase, make the utility easier to consume, and ensure the test suite reliably validates the intended behavior. Happy coding!