# Background

Analisis ini dilakukan untuk mereview codebase backoffice-web yang nantinya akan digunakan oleh berbagai produk (Retail, Loyalty, Lending, Merchant) dan melibatkan banyak developer. Tujuan utamanya adalah untuk mengidentifikasi area mana pada codebase yang dapat di-*improve* sehingga dapat mempercepat proses development dan membantu developer baru dalam menavigasi dan memahami codebase.

---

# Component Library

## Buttons

Saat ini, backoffice-web memiliki component `stdr-button-default` yang seharusnya menjadi komponen button default yang digunakan untuk setiap button. Akan tetapi, komponen ini hanya digunakan 16 kali dalam 9 files.


Bila dibandingkan dengan penggunaan komponen `p-button` dari PrimeNG dan native HTML `button`, penggunaan `stdr-button-default` jauh lebih sedikit. Implikasinya adalah, setiap kali `p-button` dan `button` digunakan, perlu ada pengaturan styling tambahan untuk menyesuaikan tampilan button dengan design Figma.


Design komponen button di Figma cukup konsisten karena hanya terdapat beberapa variasi warna, bentuk, dan ukuran. Komponen `stdr-button-default` dapat digunakan optimal oleh developer apabila dapat mengakomodasi setiap variasi tersebut. Implikasinya apabila developer menggunakan komponen ini dapat mempermudah proses development karena tidak perlu mendefinisikan styling setiap kali button digunakan.

> **Pain Points**
> - Komponen `stdr-button-default` hanya menyediakan pilihan warna `black`, `orange`, `white`, dan `customIcon`. Keterbatasan ini membuat komponen tersebut kurang reusable.
> - Setiap kali `p-button` dan `button` digunakan, perlu ada pengaturan styling tambahan untuk menyesuaikan tampilan button dengan design Figma.

**Usulan**:
- Extend styling dari `p-button` supaya dapat digunakan sebagai property pada `stdr-button-default`. Dengan begini, `stdr-button-default` dapat di-*reuse* dengan lebih fleksibel (ukuran, roundedness, warna, icon, dll).
- Rename komponen menjadi `bankmas-button`, sebab menggunakan singkatan dalam penamaan bukan practice yang baik.
- Menambahkan informasi how-to-use dalam komponen (berupa comments) untuk setiap property yang dapat di-*customize*.

## Search & Filters

Saat ini, terdapat dua cara melakukan search dan filter pada desain backoffice-web.
1. Via action bar di bagian atas halaman (simple search)
2. Via sidebar (advanced search & filter)

Komponen yang mewakili fungsionalitas ini adalah `identification-list`. Dalam implementasinya, komponen ini berisi:
1. Dropdown filter (untuk mencari berdasarkan apa)
2. Input untuk search keyword
3. Button tambahan

Implementasi komponen memiliki method dan property yang spesifik untuk module tertentu. Cuplikan di bawah menunjukkan bagian implementasi spesifik yang hanya bermanfaat untuk module `customer-management`. Sebaiknya, properti-properti dengan nilai spesifik tersebut didefinisikan saat komponen digunakan dalam module tanpa memodifikasi komponen secara langsung.

setUpManipulationPlaceholder = () => {
    if (this.orderByFiled == 'phoneNumber' && _.includes(this.currentUrl, 'customer-management')) {
      this.labelPlaceholder = "Cari berdasarkan no telp.";
      this.isNumberInput = true;
    }
  };

<p-dropdown
    optionLabel="description" optionValue="recid"
    ...
>

Penamaan `optionLabel` dan `optionValue` di atas, bila tidak dispesifikasikan, akan berisi `label` dan `value`. Konteks penamaan `description` dan `recid` mungkin dibuat spesifik untuk modul tertentu, seperti pencarian customer pada customer management dan OOB report karena `recid` mewakili Record Identifier (email, nomor KTP, phoneNumber, dll). Namun konteks penamaan ini kurang cocok untuk modul lainnya. Menggunakan penamaan yang lebih *common*, yaitu `label` dan `value` dapat membuat komponen lebih generic dan reusable dalam berbagai konteks.

Komponen `p-inputText` yang digunakan dalam komponen ini memiliki property seperti `type`, `minLength`, `maxLength`, dan `pKeyFilter` yang dapat membuatnya lebih fleksibel digunakan. Akan tetapi, implementasi saat ini menggunakan switch case yang hardcoded berdasarkan property `orderByFiled`. Untuk menerapkan open-closed principle, sebaiknya setiap property dijadikan `@Input` supaya dapat diatur langsung oleh module yang membutuhkannya.

<div [ngSwitch]="orderByFiled" *ngIf="isFilter">
      <div *ngSwitchCase="'email'">
        <input
          type="email"
          ...
        />
      </div>
      <div *ngSwitchCase="'identityCardNumber'">
        <input
          type="text"
          maxlength="16"
          minlength="16"
          pKeyFilter="int"
          ...
        />
      </div>
      <div *ngSwitchCase="'phoneNumber'">
        <input
          type="text"
          maxlength="13"
          minlength="9"
          pKeyFilter="int"
          ...
        />
      </div>
      <div *ngSwitchCase="'applicationNumber'">
        <input type="text" inaPhonenumberFormat maxlength="16" minlength="9" pInputText pKeyFilter="int" ... />
      </div>
      <div *ngSwitchDefault>
        <input
          type="text"
          ...
        />
      </div>
    </div>

Komponen ini diimplementasikan cukup spesifik kepada module yang sudah memakainya, sehingga tidak menerapkan open-closed principle (open for extension, but closed for modification) maupun single responsibility principle.

> **Pain Point**
> Komponen ini memerlukan adjustment setiap kali ada module baru yang memerlukannya, sehingga berpotensi menimbulkan conflict dan bugs baru. Implikasinya, proses development memerlukan waktu yang lebih lama dan memerlukan testing ulang pada setiap modul yang terdampak.

**Usulan:**
- Extract komponen input search menjadi komponen independen `bankmas-search-box` dengan implementasi search, debouncing, dan styling seperlunya yang mudah di-*extend*. (misal: menggunakan class PrimeFlex)
- Pindahkan implementasi button tambahan ke component yang membutuhkannya saja.
- Pindahkan implementasi spesifik ke component yang membutuhkannya saja.
- Extend property dari `p-inputText` supaya komponen dapat di-*reuse* dengan lebih fleksibel.

# Naming Conventions & Typos

Saat ini, terdapat beberapa penamaan yang dapat diperjelas untuk mempermudah navigasi dalam codebase.

Sebagai contoh, nama komponen `app-identification-list` yang disebut pada bagian sebelumnya kurang mewakili peran maupun fungsi dari komponen tersebut. Penamaan ini mengimplikasikan komponen yang mengandung Daftar Identifikasi, meski sebenarnya komponen ini berisi filter, search input, dan button. Nama yang lebih cocok mungkin `app-search-bar`, `app-identification-search`, atau bila komponen di-*reduce* hingga hanya mengandung search dan filter saja, bisa dinamakan `bankmas-search-box` .

Selebihnya, ditemukan beberapa typo yang lolos code review dan belum diperbaiki.
1. `orderByFiled` → `orderByField` (?) 

2. folder `strd-button` → `stdr-button` (sebaiknya di-*rename* menjadi `standard-button` atau `bankmas-button` saja untuk mengurangi penggunaan singkatan).

3. `agragatorList` → `aggregatorList` 

4. `setAccesMenu` → `setAccessMenu` ![[1-setaccessmenu.png]]

> **Pain Point**
> Typo dan penamaan yang kurang clear berpotensi membingungkan developer dalam menavigasi dan memahami codebase.

**Usulan:**
- Gunakan naming convention yang sesuai dengan style guide
- Perbaiki typo dalam proses merge request/review

Referensi: [Angular - Angular coding style guide](https://angular.io/guide/styleguide)

# Styling

Saat ini, terdapat tiga cara untuk mengatur styling pada backoffice-web.
1. Menggunakan stylesheets `.scss`
2. Menggunakan inline style
3. Menggunakan CSS class dari PrimeFlex

Karena tidak ada standar yang disepakati, pengaturan styling diserahkan pada preferensi developer masing-masing. Hal ini menimbulkan isu saat debugging karena styling yang berpotensi tumpang tindih.

**Usulan:**
- Maksimalkan penggunaan CSS class dari PrimeFlex (learning curve cukup landai, lebih mudah lagi bila familiar dengan BootstrapCSS atau TailwindCSS)
- Minimalkan penggunaan inline styling
- Gunakan stylesheets seperlunya saja (misal untuk mengatur styling komponen PrimeNG yang tidak bisa dilakukan melalui properti `styleClass`)

# Formatting

Saat ini, formatting pada codebase tidak seragam. Terdapat file `.prettierrc`, tetapi konfigurasinya tidak diterapkan di sebagian besar file dalam codebase. Hal ini menyebabkan changes yang lebih banyak dari yang seharusnya karena ada perubahan formatting. Melakukan `Save without Formatting` hanya memecahkan masalah dalam jangka pendek.

Konfigurasi prettier yang disarankan:

{
    "tabWidth": 2, // tadinya 6 -> 2 supaya lebih readable
    "singleQuote": false,
    "printWidth": 100, 
    "semi": false,
    "bracketSpacing": true, // tadinya false -> true
    "arrowParens": "always"
}

**Usulan:**
- Terapkan formatting yang seragam untuk setiap file
- Gunakan auto-formatter seperti `formatOnSave` pada VS Code