Oddziel logikę od warstwy UI dzięki typowi Enum

Co najmniej kilka razy już widziałem w kodzie Enuma, który ma bezpośrednio przypisane wartości.

Przykład poniżej.

enum PaymentStatus {
    Pending = "PENDING",     
    Paid = "PAID",  
    Rejected = "REJECTED",   
}

Takie podejście prowadzi do potencjalnych problemów na przyszłość:

• wiąże logikę z warstwą UI,
• utrudnia tłumaczenia,
• komplikuje testy,
• zwiększa ryzyko błędów w komunikacji frontend–backend.

Załóżmy, że używamy PaymentStatus w komponencie PaymentBadge:

function PaymentBadge(status: PaymentStatus) {
    return <span className={`badge-${status.toLowerCase()}`}>{status}</span>
}

Jeśli chcemy zmienić widoczny tekst lub klasę to musimy edytować Enum lub dodać funkcję pomocniczą. Im większy system, tym większy ból.

To jest tylko jeden z problemów, z którym może przyjść nam się zmierzyć w trakcie rozwoju aplikacji.

Traktowanie Enumu jako czysto logicznego symbolu istotnie ułatwi nam pracę.

enum PaymentStatus {
    Pending,     
    Paid,  
    Rejected,   
}

Teraz możemy stworzyć pomocnicze funkcje mapujące wymagane wartości.

const statusLabel = new Map<PaymentStatus, string>([
  [PaymentStatus.Pending,      'Waiting'],
  [PaymentStatus.Paid,         'Completed'],
  [PaymentStatus.Rejected,     'Failed'],
]);

const statusColorValues = new Map<PaymentStatus, string>([
  [PaymentStatus.Pending,      'red'],
  [PaymentStatus.Paid,         'blue'],
  [PaymentStatus.Rejected,     'green'],
]);

Komponent PaymentBadge po aktualizacji.

function PaymentBadge(status: PaymentStatus) {
    return <span class={`badge-${statusColorValues.get(status)}`}>
    {statusLabel.get(status)}</span>
}

Tym podejściem poluzowaliśmy warstwę wizualną od logiki. W rezultacie omawiany Enum staje się jednym źródłem prawdy na temat stanu, a nie sposobu prezentacji, tłumaczenia czy serializacji.

Powrót do artykułów