---
# System prepended metadata

title: Gnoswap Interface Refactoring

---

# Gnoswap Interface Refactoring

## Summary

Define refactoring rules to improve the performance of your gnoswap and clean up its code.

## Goals

1. Separate layers and define roles.
2. Separate complex UI components and remove duplicate UI components.
3. Define business logic as testable pure functions.
4. Write with a unified naming convention.
5. Clean up utility function.
6. Add test code.

## Layers
Layers have a role per hierarchy. 
A layer should only fulfill the roles it has. 

### Page
- Returns a `Layout` component 
- Handling page data and injecting data into `Container`
- Page data-related hooks are available

### Layout
- Renders the structure of the UI 
- The content of the layout is injected from the `Page`

### Container
- Returns the 1:1 corresponding `Component`
- Call the `Hook` and process the data
- Passes data to the `Component ``

### Component
- Returns a UI component
- Doesn't handle logic and does simple data mapping
- Components used more than once are defined as common

### Hook
- Returns variables and functions used on a `Page` or `Container`
- Managing stateful variables
- Managing React Queries
- Handle service functions (from `Service Layer`)
- Handling errors when using service functions

### Service (Considered)
- Implementing service functions 
- Managed as pure functions and should be mockable
- Have access to a `Repository`
- Throw a custom error when a function throws an exception 
- Mapping responses from Repository functions to models 

### Repository
- Implemented the part that fetches data (Wallet, API, RPC ...) 
- Managed as pure functions and should be mockable
- Repository defines Request/Response data types per function 
- Throw a custom error when a function throws an exception 

### Model
- Data models used in Gnoswap 

## Conventions

### Naming Conventions
- Directory: `kebab-case`
- File: `kebab-case` (default), `PascalCase` (`Component` Files)
    - Style File: [name].styles.ts
    - Test file: [name].spec.ts
    - Story file: [name].stories.ts
    - Utility file: [name].utils.ts
    - Constant variable file: [name].constant.ts
- Constant variable: `UPPER_SNAKE_CASE`
- Interface: `PascalCase`
- Class: `PascalCase`
- Function: `camelCase`
- Variable: `camelCase`

### Project Basic struct
- `common`: common modules
- `components`: UI components
- `constants`: Static variables
- `containers`: Container components
- `hooks`: Hooks
- `layouts`: Layout components
- `models`: Service data models
- `pages`: Page components
- `providers`: React providers, Provide a `Service` instance 
- `repositories`: Data access repositories
- `resources`: public routing static files
- `services`: Service logic
- `states`: Stateful variables
- `utils`: Utility functions

### Container Checklist
- Don't add UI beyond the container and its corresponding components 
- Aims to combine functions in Hooks in a way that makes it easy to handle

### Component Checklist
- Component state variables may not be necessary 
- Separate components if they're large 
- Consider separating common components if you're checking for similar components 
- Increase the utilization of style components (reduce the use of className).
- Added JEST test code
- Added storybook code 

### Hook Checklist
- Hook names should be descriptive of the behavior
- Avoid useEffect in your hooks and lean towards using reactQuery
- Hooks should match the topic of the current directory
 
### Service & Repository Checklist
- Handles expected errors as custom errors (validation, number compare ...)
- Develop for mocking 
- Added jest test code 

## Task planning
- Discussion..