refactor: standardize property naming conventions in backend schemas (#30)

* refactor: standardize property naming conventions in backend schemas and related components

* chore: lint

Author: HermanPlay

.github/copilot-instructions.md

@@ -926,39 +926,39 @@ Forms containing `<input type="file">` must use `enctype="multipart/form-data"`.
 
 # SVELTEKIT + TAILWIND + TYPESCRIPT OPERATIONAL GUIDELINES
 
-## PRIME DIRECTIVE  
-Always prioritize maintainability, accessibility, and clean developer ergonomics.  
-Collaborate via conversation while coding — **explain what, how, and why**.  
+## PRIME DIRECTIVE
+Always prioritize maintainability, accessibility, and clean developer ergonomics.
+Collaborate via conversation while coding — **explain what, how, and why**.
 Avoid making multiple concurrent changes to the same file to prevent conflict or corruption.
 
 ---
 
 ## LARGE FILE & COMPLEX CHANGE PROTOCOL
 
-### MANDATORY PLANNING PHASE  
-When editing files larger than 300 lines or implementing deeply integrated features:  
+### MANDATORY PLANNING PHASE
+When editing files larger than 300 lines or implementing deeply integrated features:
 
-1. **Always begin with a detailed, structured edit plan**  
+1. **Always begin with a detailed, structured edit plan**
 2. The plan must include:
    - A breakdown of all affected components, stores, routes, or layouts
    - The order of operations for each edit
    - Dependencies and known side effects
-   - An estimated count of isolated edits required  
+   - An estimated count of isolated edits required
 
-**Plan format**:  
+**Plan format**:
 ```md
-## PROPOSED EDIT PLAN  
-Working with: [filename or route]  
-Total planned edits: [number]  
+## PROPOSED EDIT PLAN
+Working with: [filename or route]
+Total planned edits: [number]
 ```
 
 ---
 
-### MAKING EDITS  
-- Focus on **one conceptual change at a time**  
-- Use "before/after" snippets to demonstrate changes  
-- Explain the **purpose** and benefit of each change clearly  
-- Ensure edits comply with the project’s structure and coding conventions  
+### MAKING EDITS
+- Focus on **one conceptual change at a time**
+- Use "before/after" snippets to demonstrate changes
+- Explain the **purpose** and benefit of each change clearly
+- Ensure edits comply with the project’s structure and coding conventions
 
 **Edit Sequence Template**:
 ```md
@@ -969,9 +969,9 @@ Do you approve this plan? I will proceed with Edit [#] upon your confirmation.
 
 ---
 
-### EXECUTION PHASE  
-- After completing each step:  
-	✅ Completed edit [#] of [total]. Ready for next edit?  
+### EXECUTION PHASE
+- After completing each step:
+	✅ Completed edit [#] of [total]. Ready for next edit?
 - If additional issues arise, **pause**, revise the plan, and **seek user approval before continuing**
 
 ---
@@ -985,46 +985,46 @@ Use the following folder layout:
 messages/             # Paraglide translations
 src/
 ├── lib/              # Reusable UI components and utilities
-│   ├── components/   
+│   ├── components/
 ├── routes/           # SvelteKit endpoints, pages, and layouts
 ├── app.d.ts          # App-wide type definitions
 └── hooks.server.ts   # Server hooks for session/auth
 ```
 
 ---
 
-### TYPING & TOOLING  
+### TYPING & TOOLING
 - Use **TypeScript 5.7+** syntax and features
 - Prefer **Zod** for runtime validation and schema definition
 - Ensure all components and functions are typed strictly
 - Use `readonly` for immutable structures when possible
 
 ---
 
-### UI COMPONENTS  
-- Use `bits-ui`, `lucide-svelte`, and `tailwind-variants` for consistent styling  
-- Create generic variants using **tailwind-variants** for composability  
-- Favor `clsx` for class merging where conditional logic is needed  
+### UI COMPONENTS
+- Use `bits-ui`, `lucide-svelte`, and `tailwind-variants` for consistent styling
+- Create generic variants using **tailwind-variants** for composability
+- Favor `clsx` for class merging where conditional logic is needed
 
 ---
 
-### STYLING  
-- Use **Tailwind CSS 3.4+**  
-- Leverage `tailwind-merge` to prevent class duplication  
-- Enable `prefers-color-scheme` dark mode  
-- Use `tailwindcss-animate` for smooth, native animations  
+### STYLING
+- Use **Tailwind CSS 3.4+**
+- Leverage `tailwind-merge` to prevent class duplication
+- Enable `prefers-color-scheme` dark mode
+- Use `tailwindcss-animate` for smooth, native animations
 - Organize custom styles using component-scoped `<style>` blocks or utility classes
 
 ---
 
-### FORM MANAGEMENT  
-- Use **sveltekit-superforms** with **Zod** for server-enhanced forms  
-- Apply `formsnap` components where structured UI patterns are needed  
-- Always display validation feedback using `aria-invalid`, `aria-describedby`, etc.  
+### FORM MANAGEMENT
+- Use **sveltekit-superforms** with **Zod** for server-enhanced forms
+- Apply `formsnap` components where structured UI patterns are needed
+- Always display validation feedback using `aria-invalid`, `aria-describedby`, etc.
 
 ---
 
-### ACCESSIBILITY  
+### ACCESSIBILITY
 Always meet **WCAG 2.1 AA minimum**, AAA where feasible:
 - Use semantic HTML tags (`<main>`, `<section>`, etc.)
 - Add labels and `aria-*` attributes to interactive elements
@@ -1033,55 +1033,55 @@ Always meet **WCAG 2.1 AA minimum**, AAA where feasible:
 
 ---
 
-### ESLINT & FORMATTER  
-- Use **ESLint 9+** and **Prettier 3+**  
-- Extend from `eslint-config-prettier` and `eslint-plugin-svelte`  
-- Auto-format with `prettier-plugin-svelte`  
+### ESLINT & FORMATTER
+- Use **ESLint 9+** and **Prettier 3+**
+- Extend from `eslint-config-prettier` and `eslint-plugin-svelte`
+- Auto-format with `prettier-plugin-svelte`
 - TypeScript rules managed via `typescript-eslint`
 
 ---
 
-### TESTING  
-- Use **Vitest** for unit and integration testing  
-- Use **Playwright** (recommended, not listed but consider) for E2E  
-- Prefer `describe`, `test`, `expect` for clarity  
+### TESTING
+- Use **Vitest** for unit and integration testing
+- Use **Playwright** (recommended, not listed but consider) for E2E
+- Prefer `describe`, `test`, `expect` for clarity
 - Structure tests under `/tests` with a mirrored folder structure of `/src`
 
 ---
 
-### PERFORMANCE & BUNDLING  
-- Use **Vite 5** with **@sveltejs/vite-plugin-svelte**  
-- Enable code-splitting via dynamic imports  
-- Optimize assets (use `WebP`, `AVIF`, lazy loading)  
-- Use `@iconify-json/flag` and `unplugin-icons` for scalable icon support  
+### PERFORMANCE & BUNDLING
+- Use **Vite 5** with **@sveltejs/vite-plugin-svelte**
+- Enable code-splitting via dynamic imports
+- Optimize assets (use `WebP`, `AVIF`, lazy loading)
+- Use `@iconify-json/flag` and `unplugin-icons` for scalable icon support
 
 ---
 
-### ERROR HANDLING  
-- Use `try/catch` consistently in load functions and API calls  
-- Provide user-friendly messages via `svelte-sonner`  
-- Log dev details to the console or a remote logger when applicable  
+### ERROR HANDLING
+- Use `try/catch` consistently in load functions and API calls
+- Provide user-friendly messages via `svelte-sonner`
+- Log dev details to the console or a remote logger when applicable
 - Handle:
   - Network errors
   - Business logic errors
-  - Runtime exceptions  
+  - Runtime exceptions
 - Use global event handlers like `window.addEventListener('unhandledrejection')`
 
 ---
 
-## SECURITY BEST PRACTICES  
-- Sanitize all form input using Zod schemas  
-- Avoid client-side secrets (e.g., in `.env`)  
-- Enforce proper CORS and CSP headers  
-- Store cookies securely: `SameSite=Strict`, `HttpOnly`, `Secure`  
+## SECURITY BEST PRACTICES
+- Sanitize all form input using Zod schemas
+- Avoid client-side secrets (e.g., in `.env`)
+- Enforce proper CORS and CSP headers
+- Store cookies securely: `SameSite=Strict`, `HttpOnly`, `Secure`
 - Use role-based access control in hooks and endpoints
 
 ---
 
-### DEPLOYMENT CONSIDERATIONS  
-- Use **adapter-auto** for portability  
-- Consider replacing it with `adapter-vercel` or `adapter-static` depending on target platform  
-- Ensure SSR + client hydration is functioning  
+### DEPLOYMENT CONSIDERATIONS
+- Use **adapter-auto** for portability
+- Consider replacing it with `adapter-vercel` or `adapter-static` depending on target platform
+- Ensure SSR + client hydration is functioning
 - Use `.env` and `config/` files for environment-specific settings
 
 ---

src/lib/backendSchemas.ts

@@ -17,14 +17,14 @@ export interface LanguageConfig {
 	id: number;
 	language: string;
 	version: string;
-	file_extension: string;
+	fileExtension: string;
 }
 
 export interface TaskData {
 	id: number;
 	title: string;
-	description_url: string;
-	created_by: number;
+	descriptionUrl: string;
+	createdBy: number;
 }
 
 interface LanguageData {
@@ -41,14 +41,14 @@ export enum SubmissionStatus {
 
 export interface SubmissionData {
 	id: number;
-	task_id: number;
-	user_id: number;
+	taskId: number;
+	userId: number;
 	order: number;
-	language_id: number;
+	languageId: number;
 	status: SubmissionStatus;
-	status_message: string;
-	submitted_at: string;
-	checked_at: string;
+	statusMessage: string;
+	submittedAt: string;
+	checkedAt: string;
 	language: LanguageData;
 	task: TaskData;
 	user: UserData;
@@ -58,27 +58,27 @@ export interface SubmissionData {
 export interface GroupData {
 	id: number;
 	name: string;
-	created_by: number;
-	created_at: string;
-	updated_at: string;
+	createdBy: number;
+	createdAt: string;
+	updatedAt: string;
 	tasks: TaskData[] | null;
 	users: UserData[] | null;
 }
 
 interface TestResultData {
 	id: number;
-	submission_result_id: number;
-	input_output_id: number;
+	submissionResultId: number;
+	inputOutputId: number;
 	passed: boolean;
 }
 
 export interface SubmissionResultData {
 	id: number;
-	submission_id: number;
+	submissionId: number;
 	code: string;
 	message: string;
-	created_at: string;
-	test_results: TestResultData[] | null;
+	createdAt: string;
+	testResults: TestResultData[] | null;
 }
 
 interface ApiResponse {
@@ -106,10 +106,10 @@ export interface AuthSessionResponse extends ApiResponse {
 
 export interface AuthUserResponse extends ApiResponse {
 	data: {
-		user_id: number;
-		user_role: UserRole;
+		userId: number;
+		userRole: UserRole;
 		session: string;
-		expires_at: Date;
+		expiresAt: Date;
 	};
 }
 

src/lib/components/tasks/EditTaskDialog.svelte

@@ -25,7 +25,7 @@
 		editTaskForm,
 		assingTaskToGroupsForm
 	}: {
-		taskData: Omit<TaskData, 'description_url'>;
+		taskData: Omit<TaskData, 'descriptionUrl'>;
 		userGroups: GroupData[];
 		editTaskForm: SuperValidated<Infer<EditTaskSchema>>;
 		assingTaskToGroupsForm: SuperValidated<Infer<AssingTaskToGroupsSchema>>;

src/lib/components/tasks/TaskView.svelte

@@ -13,7 +13,7 @@
 	import EditTaskDialog from './EditTaskDialog.svelte';
 	import type { AssingTaskToGroupsSchema, EditTaskSchema } from './formSchemas';
 	import Button from '$components/ui/button/button.svelte';
-	import { page } from '$app/state';
+	import { page } from '$app/stores';
 
 	let {
 		localUser,
@@ -25,7 +25,7 @@
 		availableLanguages
 	}: {
 		localUser: UserData;
-		task: Omit<TaskData, 'description_url'> & {
+		task: Omit<TaskData, 'descriptionUrl'> & {
 			description_file: Promise<ArrayBuffer>;
 		};
 		editTaskForm: SuperValidated<Infer<EditTaskSchema>>;
@@ -41,11 +41,11 @@
 		availableLanguages: availableLanguages
 	};
 
-	const { taskId } = page.params;
+	const taskId = $derived($page.params.taskId);
 
 	function isAllowed() {
 		return (
-			(localUser.role === UserRole.Teacher && task.created_by === localUser.id) ||
+			(localUser.role === UserRole.Teacher && task.createdBy === localUser.id) ||
 			localUser.role === UserRole.Admin
 		);
 	}

src/lib/components/tasks/submissions/TaskAllSubmissionsView.svelte

@@ -39,7 +39,7 @@
 				>
 				<Table.Cell>{submission.language.language}</Table.Cell>
 				<Table.Cell>
-					{new Date(submission.submitted_at).toLocaleString()}
+					{new Date(submission.submittedAt).toLocaleString()}
 				</Table.Cell>
 				<Table.Cell class={get_submission_status_color(submission.status)}
 					>{submission.status}</Table.Cell

src/lib/components/users/UserView.svelte

@@ -98,7 +98,7 @@
 								>
 								<Table.Cell>{submission.language.language}</Table.Cell>
 								<Table.Cell>
-									{new Date(submission.submitted_at).toLocaleString()}
+									{new Date(submission.submittedAt).toLocaleString()}
 								</Table.Cell>
 								<Table.Cell class={get_submission_status_color(submission.status)}
 									>{submission.status}</Table.Cell

src/lib/index.ts

@@ -22,11 +22,11 @@ export function get_submission_status_color(status: string) {
 export function get_submission_passed_color(result: SubmissionResultData | null) {
 	if (!result) {
 		return 'bg-white';
-	} else if (!result.test_results) {
+	} else if (!result.testResults) {
 		return 'bg-red-200';
-	} else if (result.test_results.every((test) => test.passed)) {
+	} else if (result.testResults.every((test) => test.passed)) {
 		return 'bg-green-200';
-	} else if (result.test_results.some((test) => !test.passed)) {
+	} else if (result.testResults.some((test) => !test.passed)) {
 		return 'bg-orange-200';
 	} else {
 		return 'bg-red-200';
@@ -36,11 +36,11 @@ export function get_submission_passed_color(result: SubmissionResultData | null)
 export function get_submission_passed_text(result: SubmissionResultData | null) {
 	if (!result) {
 		return '-';
-	} else if (!result.test_results) {
+	} else if (!result.testResults) {
 		return '0/0';
 	} else {
-		const countPassed = result.test_results.filter((test) => test.passed).length;
-		const countTotal = result.test_results.length;
+		const countPassed = result.testResults.filter((test) => test.passed).length;
+		const countTotal = result.testResults.length;
 		return `${countPassed}/${countTotal}`;
 	}
 }