55239606af008e5c4e3ec5994de3a60ebd9d0936
feat(patient): add newborn status field and validation - Add radio button component for newborn status selection - Update patient schema with newborn status validation - Remove deprecated alias field from person model - Refactor disability type handling in patient schema fix(patient): correct address comparison logic and schema Update the patient address comparison to use boolean instead of string '1' and modify the schema to transform the string value to boolean. This ensures consistent type usage throughout the application. feat(models): add village and district model interfaces Add new model interfaces for Village and District with their respective generator functions. These models will be used to handle administrative division data in the application. feat(address): implement dynamic province selection with caching - Add province service for CRUD operations - Create useProvinces composable with caching and loading states - Update select-province component to use dynamic data - Export SelectItem interface for type consistency - Improve combobox styling and accessibility feat(address-form): implement dynamic regency selection with caching - Add new regency service for CRUD operations - Create useRegencies composable with caching and loading states - Update SelectRegency component to use dynamic data based on province selection - Improve placeholder and disabled state handling feat(address-form): implement dynamic district selection - Add district service for CRUD operations - Create useDistricts composable with caching and loading states - Update SelectDistrict component to use dynamic data - Remove hardcoded district options and implement regency-based filtering feat(address-form): implement dynamic village selection with caching - Add village service for CRUD operations - Create useVillages composable with caching and loading states - Update SelectVillage component to fetch villages based on district - Remove hardcoded village options in favor of API-driven data feat(address-form): improve address selection with debouncing and request deduplication - Add debouncing to prevent rapid API calls when selecting addresses - Implement request deduplication to avoid duplicate API calls - Add delayed form reset to ensure proper composable cleanup - Add isUserAction flag to force refresh when user changes selection
SIMRS - FE
RSSA - Front End
Important
Read this following instructions before doing your job
Framework Guide
Configuration
nuxt.config.ts
Nuxt configuration file.env
Some environment variables
Directory Structure for app/
app.vue: Main layoutcomponents: Contains all reusable UI components.components/content: Entry point for business logic and workflows. Pages or routes call these content components to handle API requests and process application logiccomponents/app: View-layer components that manage and present data. These are used withincontent/to render or handle specific parts of the UI, and return results back to the contentcomponents/pub: Public/shared components used across different parts of the app.composables: Contains reusable logic and utility functions (e.g. composables, hooks)..layouts: Reusable UI layout patterns used across pages.models: Contains data definitions or interfaces.schemas: Contains JSON schemas used for validation.services: Contains reusable API calls and business logic.
Directory Structure for app/pages
pages/auth: Authentication related pages.pages/(features): Grouped feature modules that reflect specific business content or domains.
Directory Structure for server/
server/api: API or proxy requests
Workflows
The basic development workflow follows these steps:
Define Your Data in models/
- Create data definitions or interfaces.
- These should represent the structure of the data used across your app.
Build UI Components in components/app
- Create reusable UI and app specific components.
- Keep components pure, avoid making HTTP requests directly within them.
- They receive data via props and emit events upward.
Business Logic in components/content
- This layer connects the UI with the logic (API calls, validations, navigation).
- It composes components from
components/app/,components/pub/, and other content. - Also responsible for managing state, side effects, and interactions.
Create Pages in pages/
- Define permissions and guards for each page.
- Pages load the appropriate content from
components/content/. - They do not contain UI or logic directly, just route level layout or guards.
Validation
-
UI level validation in
components/app. help users avoid mistakes before submitting.- Lightweight/instant validation related to UX.
- Basic formatting (email regex, numeric-only, password length).
- Showing error messages directly under the field.
-
Business level validation in
components/flow. cannot rely only on the UI, since it often requires server-side checks or rules that may change.- More complex validation rules tied to business logic.
Code Conventions
- Under the script setup block, putting things in group with the following order:
- Imports → all dependencies, sorted by external, alias (~), and relative imports.
- Props & Emits → clearly define component inputs & outputs.
- State & Computed → all ref, reactive, and computed variables grouped together.
- Lifecycle Hooks → grouped by mounting → updating → unmounting order.
- Functions → async first (fetching, API calls), then utility & event handlers.
- Watchers → if needed, put them at the bottom.
- Template → keep clean and minimal logic, use methods/computed instead of inline JS.
- Declaration Naming
- Uses PascalCase for
typenaming - Uses camelCase for
variableandconstnaming - Underscore can be used to indicates that a variable has derived from an attribute of an object
for example:person_nameindicates it is an attributenamefrom objectperson
- Uses PascalCase for
- Looping
- Uses
i,j,kas variable forforlooping index - Uses
itemas object instantition forforEachloop callback - Uses
itemas object instantition forv-forloop callback in the template
- Uses
Git Workflows
The basic git workflow follows these steps:
- Create a new branch on
dev- branch name should be
feat/<feature-name>orfix/<bug-name>
- branch name should be
- Make your changes
- Commit your changes
- commit msg format:
[type]: [description]typecan befeat,fix,docs,style,refactor,perf,test,build,ci,chore,revertdescriptionshould be a brief description of the changes- Example:
feat: add new feature
- commit msg format:
- Push your changes to
dev - Create a pull request from
devtomain
Description