113 lines
4.6 KiB
Markdown
113 lines
4.6 KiB
Markdown
# 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`<br />Nuxt configuration file
|
|
- `.env`<br />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<br />
|
|
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/<feature-name>` or `fix/<bug-name>`
|
|
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`
|