Use Modal When Adding Game to List #23

New issue

Open

opened 2024-01-14 14:27:30 -06:00 by jimmyb · 1 comment

jimmyb commented

2024-01-14 14:27:30 -06:00

Owner

Copy link

As a user, I want to add a game to my list without leaving the page I am on so the add-to-list flow feels faster and does not interrupt browsing.

The current Laravel checkout still points add-to-list actions at full-page URLs such as /list/add/{game} and edit actions such as /list/edit/{gameList} from the game profile action list. Public game cards on newly added, platform, and search-style listing pages also expose an Add to List link for signed-in users when the viewer has not already added the game. This issue tracks replacing that page-change flow with an in-page modal for supported game surfaces while preserving the existing game_lists persistence, validation rules, activity logging, and duplicate-state behavior.

This is a post-launch UX improvement, not a launch blocker.

Scope

In-page modal for adding a game to the signed-in user's list from supported game surfaces.
Initial supported surfaces: game profile action list, reusable x-site.game-card listings, newly added games, platform pages, and search results wherever the shared card is used.
Reuse the existing game list fields and validation expectations: status, ownership, rating, priority, difficulty, hours played, started/finished dates, replay state/value, and notes.
Preserve the current full-page add/edit routes as a fallback until the modal flow fully replaces them.
Keep existing behavior for users who already have the game on their list, including showing edit-state actions instead of duplicate add controls.
Provide clear success, validation, and failure feedback without navigating away from the current page.
Maintain light/dark mode styling and existing Laravel/Tailwind component patterns.

Acceptance Criteria

Authenticated users can open an add-to-list modal from the game profile page without a full page navigation.
Authenticated users can open the same add-to-list modal from game cards on supported listing pages without a full page navigation.
The modal shows the game name and enough context for the user to confirm they are adding the intended game.
The modal includes the same meaningful fields required by the existing add-to-list form, including list status.
Submitting the modal creates a game_lists record for the signed-in user and selected game.
Successful submission closes or clearly completes the modal, shows a success state, and updates the originating action so the user is not offered a duplicate add action.
Validation errors are displayed inside the modal without losing the user's current page context.
Guests cannot submit modal add requests and are sent through the existing authentication flow.
Users cannot add duplicate active list entries for the same game.
Existing list activity logging continues to run when a game is added through the modal.
The existing full-page add/edit routes continue to work as a fallback while this feature is being rolled out.
Modal markup and interactions are keyboard accessible, screen-reader friendly, and usable in light and dark mode.

Test Coverage Required

Feature tests for adding a game to the authenticated user's list through the modal-backed endpoint or action.
Feature tests confirming guests cannot submit add-to-list modal requests.
Validation tests for required/allowed status values and any optional fields exposed in the modal.
Regression tests confirming duplicate active game list entries are blocked for the same user/game pair.
Feature or browser-adjacent tests confirming the game profile page exposes modal add controls for eligible signed-in users.
Feature or browser-adjacent tests confirming shared game-card listings expose modal add controls for eligible signed-in users and suppress them once the viewer already has the game.
Regression tests confirming the existing full-page add/edit fallback routes still work if they remain in the codebase.
Tests should use Pest and focused feature coverage.
Run the focused affected tests, then run vendor/bin/pint --dirty --format agent before closing the issue.

Progress Checklist

game_lists persistence exists
GameListController contains add/update validation and activity logging
Game profile action list exposes Add to List / Edit List Entry links
Shared x-site.game-card exposes Add to List for eligible signed-in viewers
Newly added games, platform pages, and search results use shared game-card patterns
Add a modal-capable add-to-list endpoint or Livewire/Volt interaction that reuses existing validation and persistence rules
Add reusable modal UI for the game list fields
Wire modal launch controls into the game profile action list
Wire modal launch controls into shared game-card listings
Update page state after successful modal submission so duplicate add controls disappear
Preserve or intentionally redirect existing full-page add/edit routes as fallback behavior
Add accessible success, loading, validation, and error states inside the modal
Add tests for authenticated add, guest rejection, validation, duplicate prevention, UI exposure, and fallback routes
Confirm the feature is treated as post-launch UX polish rather than a launch blocker

As a user, I want to add a game to my list without leaving the page I am on so the add-to-list flow feels faster and does not interrupt browsing. The current Laravel checkout still points add-to-list actions at full-page URLs such as `/list/add/{game}` and edit actions such as `/list/edit/{gameList}` from the game profile action list. Public game cards on newly added, platform, and search-style listing pages also expose an `Add to List` link for signed-in users when the viewer has not already added the game. This issue tracks replacing that page-change flow with an in-page modal for supported game surfaces while preserving the existing `game_lists` persistence, validation rules, activity logging, and duplicate-state behavior. This is a post-launch UX improvement, not a launch blocker. ## Scope - In-page modal for adding a game to the signed-in user's list from supported game surfaces. - Initial supported surfaces: game profile action list, reusable `x-site.game-card` listings, newly added games, platform pages, and search results wherever the shared card is used. - Reuse the existing game list fields and validation expectations: status, ownership, rating, priority, difficulty, hours played, started/finished dates, replay state/value, and notes. - Preserve the current full-page add/edit routes as a fallback until the modal flow fully replaces them. - Keep existing behavior for users who already have the game on their list, including showing edit-state actions instead of duplicate add controls. - Provide clear success, validation, and failure feedback without navigating away from the current page. - Maintain light/dark mode styling and existing Laravel/Tailwind component patterns. ## Acceptance Criteria - Authenticated users can open an add-to-list modal from the game profile page without a full page navigation. - Authenticated users can open the same add-to-list modal from game cards on supported listing pages without a full page navigation. - The modal shows the game name and enough context for the user to confirm they are adding the intended game. - The modal includes the same meaningful fields required by the existing add-to-list form, including list status. - Submitting the modal creates a `game_lists` record for the signed-in user and selected game. - Successful submission closes or clearly completes the modal, shows a success state, and updates the originating action so the user is not offered a duplicate add action. - Validation errors are displayed inside the modal without losing the user's current page context. - Guests cannot submit modal add requests and are sent through the existing authentication flow. - Users cannot add duplicate active list entries for the same game. - Existing list activity logging continues to run when a game is added through the modal. - The existing full-page add/edit routes continue to work as a fallback while this feature is being rolled out. - Modal markup and interactions are keyboard accessible, screen-reader friendly, and usable in light and dark mode. ## Test Coverage Required - Feature tests for adding a game to the authenticated user's list through the modal-backed endpoint or action. - Feature tests confirming guests cannot submit add-to-list modal requests. - Validation tests for required/allowed status values and any optional fields exposed in the modal. - Regression tests confirming duplicate active game list entries are blocked for the same user/game pair. - Feature or browser-adjacent tests confirming the game profile page exposes modal add controls for eligible signed-in users. - Feature or browser-adjacent tests confirming shared game-card listings expose modal add controls for eligible signed-in users and suppress them once the viewer already has the game. - Regression tests confirming the existing full-page add/edit fallback routes still work if they remain in the codebase. - Tests should use Pest and focused feature coverage. - Run the focused affected tests, then run `vendor/bin/pint --dirty --format agent` before closing the issue. ## Progress Checklist - [x] `game_lists` persistence exists - [x] `GameListController` contains add/update validation and activity logging - [x] Game profile action list exposes `Add to List` / `Edit List Entry` links - [x] Shared `x-site.game-card` exposes `Add to List` for eligible signed-in viewers - [x] Newly added games, platform pages, and search results use shared game-card patterns - [ ] Add a modal-capable add-to-list endpoint or Livewire/Volt interaction that reuses existing validation and persistence rules - [ ] Add reusable modal UI for the game list fields - [ ] Wire modal launch controls into the game profile action list - [ ] Wire modal launch controls into shared game-card listings - [ ] Update page state after successful modal submission so duplicate add controls disappear - [ ] Preserve or intentionally redirect existing full-page add/edit routes as fallback behavior - [ ] Add accessible success, loading, validation, and error states inside the modal - [ ] Add tests for authenticated add, guest rejection, validation, duplicate prevention, UI exposure, and fallback routes - [ ] Confirm the feature is treated as post-launch UX polish rather than a launch blocker

jimmyb added the

type: improvement

component: web design

component: backend

labels

2024-01-14 14:27:30 -06:00

jimmyb commented

2024-01-14 14:27:36 -06:00

Author

Owner

Copy link

Moving this out of this project as I don't think it's something that we need to launch with.