Implement frontend GraphQL integration, tests and tooling

.env.example

@@ -0,0 +1,4 @@
+# GraphQL-endepunkt for frontend.
+# La variabelen være tom ved lokal utvikling for å bruke Vite-proxyen.
+# Ved produksjonsbygg kan den settes til /project2/graphql.
+VITE_GRAPHQL_URL=

.prettierignore

@@ -0,0 +1,5 @@
+node_modules
+dist
+coverage
+playwright-report
+test-results

.prettierrc.json

@@ -0,0 +1,7 @@
+{
+  "singleQuote": true,
+  "semi": false,
+  "trailingComma": "all",
+  "tabWidth": 2,
+  "printWidth": 80
+}

docs/frontend.md

@@ -0,0 +1,301 @@
+# Frontend Documentation
+
+## 1. Introduction
+
+The frontend of *Spillkveld* is developed using React and TypeScript, with Vite as 
+the development and build tool.
+
+The application allows users to browse a catalog of board games, search for specific games, 
+apply filters, sort results, and view detailed information about individual games. 
+Users can also create a personal selection of games, which is preserved in the browser 
+using local storage.
+
+The frontend uses Apollo Client to manage GraphQL queries and communicate with the backend. 
+During frontend development, mocked GraphQL responses are used to test functionality 
+independently of the backend implementation.
+
+## 2. Technology Stack
+
+The frontend uses the following technologies:
+
+- **React:** Component-based user interface.
+- **TypeScript:** Static typing for improved maintainability and reliability.
+- **Vite:** Development server and production build tool.
+- **Apollo Client:** GraphQL queries, caching, and client-side data management.
+- **GraphQL:** API interface between the frontend and backend.
+- **Vitest:** Unit and component testing.
+- **React Testing Library:** Testing user interactions and rendered components.
+- **Prettier:** Consistent code formatting.
+- **ESLint:** Static code analysis and linting.
+- **Playwright:** Dependency and test command prepared for end-to-end testing.
+
+## 3. Frontend Architecture
+
+The frontend is organized into separate modules for the user interface, GraphQL operations, 
+application data, and utility functions.
+
+### 3.1 Project Structure
+
+The main frontend files and directories are:
+
+- `src/App.tsx` – Main application component, including the game catalog, search, filtering, 
+                  sorting, pagination, game details, and game selection.
+- `src/main.tsx` – Application entry point and Apollo Provider setup.
+- `src/lib/apollo.ts` – Apollo Client configuration and GraphQL endpoint.
+- `src/graphql/queries.ts` – GraphQL queries used by the frontend.
+- `src/graphql/types.ts` – TypeScript definitions for GraphQL data and variables.
+- `src/graphql/mocks.ts` – Mocked GraphQL responses used during frontend development and testing.
+- `src/data/games.ts` – Sample board game data used by the mock implementation.
+- `src/lib/catalog.ts` – Catalog filtering, sorting, and pagination logic for mocked data.
+- `src/lib/selection.ts` – Local storage utilities for managing the user's selected games.
+- `src/test/setup.ts` – Test environment configuration.
+
+### 3.2 Apollo Client and GraphQL
+
+Apollo Client is configured in `src/lib/apollo.ts` and provided to the React application 
+through `ApolloProvider` in `src/main.tsx`.
+
+The frontend uses GraphQL queries to retrieve game information instead of accessing
+ the sample data directly from the UI components.
+
+The following operations are defined:
+
+- `GET_GAMES` – Retrieves a paginated game catalog with search, filtering, and sorting parameters.
+- `GET_GAME` – Retrieves detailed information about a specific game.
+- `GET_CATEGORIES` – Retrieves the available game categories.
+- `GET_GAMES_BY_IDS` – Retrieves games belonging to the user's selection.
+
+The GraphQL endpoint can be configured through the `VITE_GRAPHQL_URL` environment 
+variable. During local development, the default `/graphql` path is forwarded to the
+backend through the Vite development proxy.
+
+### 3.3 Mocked Data
+
+The frontend can be tested independently of the backend by using Apollo's `MockLink`.
+
+Mocked GraphQL responses are generated from the sample games in `src/data/games.ts`. 
+The mock implementation supports the same queries and input parameters expected 
+by the frontend.
+
+This allows frontend functionality
+
+## 4. User Interface and Features
+
+### 4.1 Game Catalog
+
+The main page displays a catalog of board games. Each game is presented with relevant 
+information, allowing users to browse the available games and open a detailed view.
+
+The catalog data is retrieved through the `GET_GAMES` GraphQL query using Apollo Client.
+
+The interface includes loading, error, and empty-result states to provide feedback 
+when data is being fetched, a request fails, or no games match the selected criteria.
+
+### 4.2 Search and Filtering
+
+Users can search for board games by entering text in the search field.
+
+The search input uses a 300-millisecond debounce to avoid sending a new query for 
+every keystroke.
+
+The catalog also supports filtering based on player count, maximum playing time, 
+and game category.
+
+These parameters are passed to the `GET_GAMES` GraphQL query, allowing the catalog 
+results to reflect the user's selected criteria.
+
+### 4.3 Sorting and Pagination
+
+Users can sort the game catalog by name or playing time.
+
+The catalog uses pagination, displaying six games per page. Users can navigate 
+between pages to browse additional results.
+
+Search, filtering, sorting, and pagination are handled through GraphQL query variables.
+
+### 4.4 Game Details
+
+Users can open a game to view additional information, including its description, 
+player count, playing time, and category.
+
+The detailed information is retrieved through the `GET_GAME` GraphQL query.
+
+The interface also handles loading and error states when retrieving game details.
+
+### 4.5 Game Selection
+
+Users can add games to a personal selection and remove games from it.
+
+The selection is stored in the browser's `localStorage`, allowing it to persist 
+across page reloads.
+
+The application stores the selected game IDs rather than complete game objects. 
+The corresponding game information is retrieved using the `GET_GAMES_BY_IDS` GraphQL query.
+
+This separates the user's locally stored selection from the game data provided 
+through GraphQL.
+
+## 5. Testing and Code Quality
+
+### 5.1 Unit and Component Testing
+
+The frontend uses Vitest and React Testing Library for automated testing.
+
+The tests cover both application logic and user interactions, including:
+
+- Searching for games and opening game details.
+- Displaying an empty state when no games match the search.
+- Adding and removing games from the selection.
+- Persisting selected games using local storage.
+- Navigating between catalog pages.
+- Retrieving game details and categories through GraphQL.
+- Handling GraphQL request failures and retrying failed requests.
+- Catalog filtering, sorting, and pagination logic.
+
+Apollo's `MockLink` is used to provide controlled GraphQL responses during component
+ tests, allowing the frontend to be tested independently of a running backend.
+
+The test files include:
+
+- `src/App.test.tsx`
+- `src/graphql/queries.test.tsx`
+- `src/lib/catalog.test.ts`
+
+The current frontend test suite contains 11 tests.
+
+Run the tests using:
+
+```bash
+npm test
+```
+
+### 5.2 Linting
+
+ESLint is used to identify potential code quality issues and enforce consistent 
+coding practices.
+
+Run ESLint using:
+
+```bash
+npm run lint
+```
+
+### 5.3 Code Formatting
+
+Prettier is configured using `.prettierrc.json`, with excluded directories defined 
+in `.prettierignore`.
+
+To automatically format the frontend source files and Vite configuration, run:
+
+```bash
+npm run format
+```
+
+To check formatting without modifying files, run:
+
+```bash
+npm run format:check
+```
+
+### 5.4 Production Build
+
+The frontend is built using TypeScript and Vite.
+
+To verify TypeScript compilation and generate the production build, run:
+
+```bash
+npm run build
+```
+
+### 5.5 End-to-End Testing
+
+Playwright has been added as a development dependency, and the following command
+is available:
+
+```bash
+npm run test:e2e
+```
+
+The implementation and configuration of Playwright end-to-end tests are handled 
+separately as part of the team's testing responsibilities.
+
+The presence of the command does not mean that the end-to-end tests have already
+been implemented or executed successfully.
+
+## 6. Development and Configuration
+
+### 6.1 Local Development
+
+The frontend uses Vite as its development server.
+
+After cloning the repository, install the project dependencies:
+
+```bash
+npm install
+```
+
+Start the development server:
+
+```bash
+npm run dev
+```
+
+The development server runs on:
+
+`http://localhost:5173`
+
+The Vite configuration uses port `5173` with `strictPort` enabled, meaning the server
+ will not automatically switch to another port if it is occupied.
+
+### 6.2 GraphQL Endpoint
+
+Apollo Client is configured in `src/lib/apollo.ts`.
+
+By default, the frontend sends GraphQL requests to `/graphql`. During local development, 
+Vite proxies these requests to:
+
+`http://127.0.0.1:3001`
+
+This allows the frontend and backend to run on separate local ports without requiring 
+the frontend to use the backend address directly.
+
+The GraphQL endpoint can be overridden using the `VITE_GRAPHQL_URL` environment variable.
+
+An `.env.example` file is provided to document this configuration.
+
+### 6.3 Production Build and Base Path
+
+The Vite configuration uses the following base path:
+
+`/project2/`
+
+This allows the frontend to be deployed under a subdirectory instead of the root 
+of a web server.
+
+The production build is generated using:
+
+```bash
+npm run build
+```
+
+The generated files are placed in the `dist` directory.
+
+For deployment under `/project2/`, the GraphQL endpoint must be configured to match 
+the backend routing. For example, if the backend is exposed at `/project2/graphql`,
+klset `VITE_GRAPHQL_URL=/project2/graphql` before building the frontend.
+
+The final deployment configuration and backend routing must be coordinated with the 
+team member responsible for deployment.
+
+### 6.4 Frontend and Backend Integration
+
+The frontend defines GraphQL queries and TypeScript types for the expected API responses.
+
+During frontend development, mocked GraphQL responses allow the interface and tests 
+to work independently of the backend.
+
+Integration with the running backend requires the backend schema to support the 
+expected queries, input parameters, and response fields.
+
+Once the backend is available, the frontend should be tested against real GraphQL 
+responses to verify that the agreed API contract is implemented correctly.