mirror of
https://github.com/pacnpal/thrillwiki_django_no_react.git
synced 2025-12-20 08:31:08 -05:00
bf7e0c0f40
- Added `useRideFiltering` composable for managing ride filters and fetching rides from the API. - Created `useParkRideFiltering` for park-specific ride filtering. - Developed `useTheme` composable for theme management with localStorage support. - Established `rideFiltering` Pinia store for centralized state management of ride filters and UI state. - Defined enhanced filter types in `filters.ts` for better type safety and clarity. - Built `RideFilteringPage.vue` to provide a user interface for filtering rides with responsive design. - Integrated filter sidebar and ride list display components for a cohesive user experience. - Added support for filter presets and search suggestions. - Implemented computed properties for active filters, average ratings, and operating counts.
50 lines
2.6 KiB
Plaintext
50 lines
2.6 KiB
Plaintext
# Project Startup & Development Rules
|
||
|
||
## Server & Package Management
|
||
- **Starting the Dev Server:** Always assume the server is running and changes have taken effect. If issues arise, run:
|
||
```bash
|
||
$PROJECT_ROOT/shared/scripts/start-servers.sh
|
||
```
|
||
- **Python Packages:** Only use UV to add packages:
|
||
```bash
|
||
cd $PROJECT_ROOT/backend && uv add <package>
|
||
```
|
||
- **Django Commands:** Always use `cd backend && uv run manage.py <command>` for all management tasks (migrations, shell, superuser, etc.). Never use `python manage.py` or `uv run python manage.py`.
|
||
|
||
## CRITICAL Frontend design rules
|
||
- EVERYTHING must support both dark and light mode.
|
||
- Make sure the light/dark mode toggle works with the Vue components and pages.
|
||
- Leverage Tailwind CSS 4 and Shadcn UI components.
|
||
|
||
## Frontend API URL Rules
|
||
- **Vite Proxy:** Always check `frontend/vite.config.ts` for proxy rules before changing frontend API URLs.
|
||
- **URL Flow:** Understand how frontend URLs are rewritten by Vite proxy (e.g., `/api/auth/login/` → `/api/v1/auth/login/`).
|
||
- **Verification:** Confirm proxy behavior via config and browser network tab. Only change URLs if proxy is NOT handling rewriting.
|
||
- **Common Mistake:** Don’t assume frontend URLs are wrong due to proxy configuration.
|
||
|
||
## Entity Relationship Patterns
|
||
- **Park:** Must have Operator (required), may have PropertyOwner (optional), cannot reference Company directly.
|
||
- **Ride:** Must belong to Park, may have Manufacturer/Designer (optional), cannot reference Company directly.
|
||
- **Entities:**
|
||
- Operators: Operate parks.
|
||
- PropertyOwners: Own park property (optional).
|
||
- Manufacturers: Make rides.
|
||
- Designers: Design rides.
|
||
- All entities can have locations.
|
||
- **Constraints:** Operator and PropertyOwner can be same or different. Manufacturers and Designers are distinct. Use proper foreign keys with correct null/blank settings.
|
||
|
||
## General Best Practices
|
||
- Never assume blank output means success—always verify changes by testing.
|
||
- Use context7 for documentation when troubleshooting.
|
||
- Document changes with conport and reasoning.
|
||
- Include relevant context and information in all changes.
|
||
- Test and validate code before deployment.
|
||
- Communicate changes clearly with your team.
|
||
- Be open to feedback and continuous improvement.
|
||
- Prioritize readability, maintainability, security, performance, scalability, and modularity.
|
||
- Use meaningful names, DRY principles, clear comments, and handle errors gracefully.
|
||
- Log important events/errors for troubleshooting.
|
||
- Prefer existing modules/packages over new code.
|
||
- Keep documentation up to date.
|
||
- Consider security vulnerabilities and performance bottlenecks in all changes.
|