# SIMRS - FE RSSA - Front End > [!IMPORTANT] > Read this following instructions before doing your job ## Framework Guide - [Vue Style Guide](https://vuejs.org/style-guide) - [Nuxt Style Guide](https://nuxt.com/docs/4.x/guide) - [Shadcn Vue @radix-ui](https://radix.shadcn-vue.com/) ## Configuration - `nuxt.config.ts`
Nuxt configuration file - `.env`
Some environment variables ## Directory Structure for `app/` - `app.vue`: Main layout - `components` : 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 logic - `components/app` : View-layer components that manage and present data. These are used within `content/` to render or handle specific parts of the UI, and return results back to the content - `components/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 `type` naming - Uses camelCase for `variable` and `const` naming - Underscore can be used to indicates that a variable has derived from an attribute of an object
for example: `person_name` indicates it is an attribute `name` from object `person` - Looping - Uses `i`, `j`, `k` as variable for `for` looping index - Uses `item` as object instantition for `forEach` loop callback - Uses `item` as object instantition for `v-for` loop callback in the template ## Git Workflows The basic git workflow follows these steps: 1. Create a new branch on `dev` - branch name should be `feat/` or `fix/` 2. Make your changes 3. Commit your changes - commit msg format: `[type]: [description]` - `type` can be `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert` - `description` should be a brief description of the changes - Example: `feat: add new feature` 4. Push your changes to `dev` 5. Create a pull request from `dev` to `main`