Memperkuat Laravel dengan Strict Typing dan Return Type Hinting

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi tiba-tiba aplikasi meledak cuma karena ada data null yang lolos masuk ke database atau return value yang nggak sesuai ekspektasi. Laravel emang fleksibel, tapi fleksibilitas itu sering jadi bumerang kalau kita nggak disiplin sama tipe data. Saya sering banget ngelihat kode yang 'kelihatan jalan', padahal menyimpan bom waktu yang bakal meledak pas user nambah banyak. Itulah kenapa pake declare(strict_types=1); dan return type hinting itu bukan cuma soal rapi-rapi kode, tapi soal tidur nyenyak pas deploy ke production.

Tips & Best Practices

• Di banyak project, biasanya saya mulai dari enforce strict type di semua file model dan service. Ini cara paling simpel buat ngejaga integritas data biar nggak ada konversi tipe data yang aneh-aneh dari PHP.
• Saya selalu terbiasa pake nullable type hint (tanda tanya sebelum tipe data) pas bikin method repository. Ini nolong banget buat ngasih sinyal ke rekan setim kalau method ini mungkin aja balik kosong, jadi mereka bisa langsung antisipasi di frontend atau controller.
• Pas lagi kolaborasi, saya suka nambahin docblock meski udah pake type hinting. Tujuannya buat IDE biar dapet auto-complete yang lebih pinter, jadi pengalaman ngoding di VS Code kerasa jauh lebih smooth.

Contoh Kode

Contohnya pas kita bikin UserService, kita pasti mau mastiin input dan output-nya jelas:

declare(strict_types=1);

namespace App\Services;

use App\Models\User;

class UserService
{
    public function findUserById(int $id): ?User
    {
        return User::find($id);
    }

    public function updateStatus(User $user, bool $isActive): void
    {
        $user->update(['is_active' => $isActive]);
    }
}

Variasi Implementasi

Ada dua pendekatan yang sering saya bandingin. Pertama, pake strict_types=1 di tiap file, yang menurut saya paling aman buat catch error di level runtime. Kedua, pake PHPStan atau Larastan buat nge-scan type hinting secara statis tanpa harus nunggu kode dijalanin. Kalau project udah gede, kombinasi keduanya itu mutlak, biar nggak cuma bergantung pada keberuntungan pas testing.

Kesalahan Umum

• Lupa naruh declare(strict_types=1) di baris paling atas file, akhirnya PHP tetep melakukan type juggling diam-diam.
• Nggak pake void return type pas method sebenernya cuma melakukan aksi (seperti update ke database), yang bikin kita bingung sendiri nanti apakah ini fungsi bakal return value atau nggak.
• Terlalu mengandalkan mixed type hint, yang sebenernya sama aja bohong karena kita jadi kehilangan keunggulan dari static typing.
• Lupa nge-handle tipe data yang datang dari request form (karena input HTTP biasanya string), yang bikin aplikasi error pas kita paksa masuk ke integer type hint.
• Terjebak nulis type hinting yang terlalu kompleks (seperti Union Types yang berlebihan) padahal desain class-nya bisa disederhanain lagi.

Ringkasan

Pada akhirnya, penggunaan strict type dan return type hinting itu soal tanggung jawab kita ke developer selanjutnya yang bakal baca kode kita. Mungkin di awal bakal berasa ribet karena harus banyak nge-fix error-error kecil, tapi percaya deh, bug yang terdeteksi pas ngetik jauh lebih murah harganya dibanding bug yang terdeteksi pas user lagi komplain di tengah malam.