DEV Community: Abd. Asis

Laravel Multilang with Inertia + React: A Real-World Guide

Abd. Asis — Wed, 04 Mar 2026 02:04:33 +0000

So you're building a Laravel + Inertia + React app and you need it to speak more than one language. Maybe your client wants both English and Indonesian. Maybe your boss just told you "make it multilingual" and walked away. Either way — welcome to this guide.

We're going to walk through a real implementation from an actual accounting app that serves both English and Indonesian users. No toy examples. No "hello world" translations. Actual production patterns that cover edge cases you'll definitely hit.

Let's go.

Why Multilang is Trickier with Inertia
The Stack
Step 1: Install laravel-react-i18n
Step 2: Wire Up the Provider in app.tsx
Step 3: Pass Locale from Laravel to React
Step 4: Structure Your Translation Files
Step 5: Use Translations in React Components
Step 6: Dynamic Values in Translations
Step 7: Build a Language Switcher
Step 8: Persist Locale Across Sessions
Step 9: Translations in the Backend
File Organization Patterns
Gotchas and Things That Will Bite You
Cheat Sheet

Why Multilang is Trickier with Inertia

In a classic server-rendered Laravel app, translations are simple — you call __('key') in your Blade views and Laravel handles everything. PHP knows the locale, renders the strings, done.

But with Inertia + React, your views render in the browser. PHP is long gone by the time the user sees the page. So you can't just call __() in your JSX — that function doesn't exist on the client.

You need a system that:

Ships translation strings to the browser
Lets React components call them
Keeps the locale in sync between PHP (for backend messages) and JavaScript (for UI strings)
Persists the user's language preference across sessions

That's exactly what we'll build.

The Stack

Laravel 12 with PHP 8.4
Inertia v2 + React 19
laravel-react-i18n — the bridge between Laravel's lang/ files and your React components

Step 1: Install laravel-react-i18n

composer require laravel-lang/common
npm install laravel-react-i18n

Then publish the config:

php artisan vendor:publish --tag=laravel-react-i18n-config

The package works by compiling your lang/ PHP files into JSON during build time and shipping them to the browser. Smart, right?

Step 2: Wire Up the Provider in app.tsx

This is where everything starts. Your resources/js/app.tsx needs to wrap the entire app in LaravelReactI18nProvider:

// resources/js/app.tsx

import { createInertiaApp } from '@inertiajs/react'
import { createRoot } from 'react-dom/client'
import { LaravelReactI18nProvider } from 'laravel-react-i18n'

createInertiaApp({
    resolve: name => {
        const pages = import.meta.glob<{ default: any }>('./pages/**/*.{jsx,tsx}', {
            eager: true,
        })
        // ... page resolution logic
    },
    setup({ el, App, props }) {
        const root = createRoot(el)

        // Read locale from Inertia's shared props
        const initialLocale = (props.initialPage.props as any).locale || 'id'

        root.render(
            <LaravelReactI18nProvider
                locale={initialLocale}
                fallbackLocale="id"
                files={import.meta.glob('/lang/*.json', { eager: true })}
            >
                <App {...props} />
            </LaravelReactI18nProvider>
        )
    },
})

A few things worth noting here:

files={import.meta.glob('/lang/*.json', { eager: true })} — this tells the provider where to find the compiled translation JSON files. Vite will bundle them at build time.
initialLocale is read from props.initialPage.props — that's Inertia's initial shared data, which we'll set up in the next step.
fallbackLocale="id" — if a key is missing in the active locale, fall back to Indonesian. Adjust this to whatever your primary language is.

Step 3: Pass Locale from Laravel to React

The locale needs to travel from PHP to JavaScript on every page load. The cleanest place to do this is in HandleInertiaRequests middleware:

// app/Http/Middleware/HandleInertiaRequests.php

use Illuminate\Support\Facades\App;

public function share(Request $request): array
{
    // Read locale from user preferences (stored in DB)
    $locale = 'id'; // default
    if (auth()->check()) {
        $preferences = auth()->user()->getPreference('general');
        $locale = $preferences['locale'] ?? 'id';
    }

    // Tell Laravel's backend to use the same locale
    // (important for __() calls on the server)
    App::setLocale($locale);

    return [
        ...parent::share($request),
        'auth' => [
            'user' => $request->user(),
        ],
        // Share locale with every Inertia page
        'locale' => $locale,
        // ... other shared data
    ];
}

This runs on every request. So every time a page loads:

Laravel reads the user's saved locale preference
Sets App::setLocale() so PHP translations work
Shares the locale via 'locale' => $locale so React can pick it up

That 'locale' key in the shared data is exactly what app.tsx reads as initialLocale above.

Step 4: Structure Your Translation Files

Here's a pattern that scales really well — one file per feature/model, with deeply nested keys:

lang/
  en/
    expense.php
    invoice.php
    over_receipt.php
    general.php
    sidebar-menu.php
  id/
    expense.php
    invoice.php
    over_receipt.php
    general.php
    sidebar-menu.php

Each file covers all the strings for that feature — page titles, form labels, table headers, toast messages, error messages, everything. Here's a real example from the expense module:

// lang/en/expense.php

return [
    // Page titles
    'title' => 'Expense Data',
    'create_title' => 'Create Expense',
    'edit_title' => 'Edit Expense',

    // Table Columns
    'columns' => [
        'transaction_date' => 'Transaction Date',
        'description' => 'Description',
        'recipient' => 'Recipient',
        'status' => 'Status',
        'total' => 'Total',
    ],

    // Form
    'form' => [
        'title' => 'Create New Expense',
        'edit_title' => 'Edit Expense :number',    // <- parameter placeholder
        'pay_from' => 'Pay From',
        'select_bank_cash' => 'Select Bank/Cash',
        'recipient' => 'Recipient',
        'memo' => 'Memo',
        'grand_total' => 'Total',
        // Toast messages
        'toast_saving' => 'Saving data...',
        'toast_save_success' => 'Expense saved successfully!',
        'toast_error' => 'Error saving data!',
    ],

    // Actions
    'actions' => [
        'create' => 'Create Expense',
        'edit' => 'Edit',
        'delete' => 'Delete',
        'print' => 'Print',
        'back' => 'Back',
    ],
];

And the matching Indonesian file:

// lang/id/expense.php

return [
    'title' => 'Data Pengeluaran',
    'create_title' => 'Buat Pengeluaran',
    'edit_title' => 'Edit Pengeluaran',

    'columns' => [
        'transaction_date' => 'Tanggal Transaksi',
        'description' => 'Deskripsi',
        'recipient' => 'Penerima',
        'status' => 'Status',
        'total' => 'Total',
    ],

    'form' => [
        'title' => 'Buat Pengeluaran Baru',
        'edit_title' => 'Edit Pengeluaran :number',
        'pay_from' => 'Bayar Dari',
        'select_bank_cash' => 'Pilih Bank/Kas',
        'recipient' => 'Penerima',
        'memo' => 'Memo',
        'grand_total' => 'Total',
        'toast_saving' => 'Sedang menyimpan data',
        'toast_save_success' => 'Pengeluaran Berhasil Disimpan!',
        'toast_error' => 'Kesalahan saat menyimpan data!',
    ],

    'actions' => [
        'create' => 'Buat Pengeluaran',
        'edit' => 'Ubah',
        'delete' => 'Hapus',
        'print' => 'Print',
        'back' => 'Kembali',
    ],
];

The key insight: both files must be maintained in parallel. Add a key to one, add it to the other. Some teams enforce this with tests; in this project it's a discipline thing.

Step 5: Use Translations in React Components

Once the provider is set up, every React component has access to the t() function via a hook:

// resources/js/pages/expense/index.tsx

import { useLaravelReactI18n } from 'laravel-react-i18n'
import { ColumnDef } from '@tanstack/react-table'

const ExpenseIndex = ({ expenses, contacts }: ExpenseIndexProps) => {
    const { t } = useLaravelReactI18n()

    const columns: ColumnDef<Expense>[] = useMemo(
        () => [
            {
                header: t('expense.columns.transaction_date'),
                // ...
            },
            {
                header: t('expense.columns.description'),
                // ...
            },
            {
                header: t('expense.columns.total'),
                // ...
            },
        ],
        [t]  // <-- important: t is a dependency
    )

    return (
        <div>
            <h1>{t('expense.title')}</h1>
            {/* ... */}
        </div>
    )
}

The t() function signature: t('file.nested.key') — where file maps to a lang/en/file.php translation file, and dots separate nested array keys.

Step 6: Dynamic Values in Translations

Sometimes your translation string needs to include a dynamic value — like an amount, a name, or a number. Laravel's :placeholder syntax works here too.

Define the key with a :placeholder:

// lang/en/over_receipt.php

'refund_form' => [
    // The :max will be replaced at runtime
    'amount_exceeds_balance' => 'Amount cannot exceed remaining credit (:max)',
],

// lang/id/over_receipt.php

'refund_form' => [
    'amount_exceeds_balance' => 'Jumlah tidak boleh lebih dari sisa kredit (:max)',
],

Then in your React component, pass the values as a second argument to t():

// resources/js/components/refund-over-receipt/refund-over-receipt-form.tsx

import { useLaravelReactI18n } from 'laravel-react-i18n'
import { toast } from 'sonner'
import { currency } from '@/utilities/Currency.js'

const handleAmountChange = (value: string) => {
    const numericValue = Number(value || 0)

    // Validate: amount cannot exceed remaining credit
    if (numericValue > available_balance) {
        toast.error(
            t('over_receipt.refund_form.amount_exceeds_balance', {
                max: currency(available_balance),   // <- dynamic value
            })
        )
        return
    }

    // ... rest of handler
}

The { max: currency(available_balance) } object maps placeholder names to their values. When the locale is en, the user sees "Amount cannot exceed remaining credit (Rp 500,000)". When it's id, they see "Jumlah tidak boleh lebih dari sisa kredit (Rp 500.000)".

Another real example — the POS session modal shows warehouse-specific messages:

// resources/js/components/pos/close-session-modal.tsx

{t('pos.close_session.no_deposit_config_description', {
    warehouse: session.warehouse?.name ?? '',
})}

Which maps to:

// lang/en/pos.php (simplified)
'no_deposit_config_description' => 'No deposit account configured for warehouse :warehouse.',

// lang/id/pos.php
'no_deposit_config_description' => 'Tidak ada akun deposit untuk gudang :warehouse.',

Step 7: Build a Language Switcher

Users need a way to actually switch languages. Here's the real component from the app:

// resources/js/components/language-switcher.tsx

import { Button } from '@/components/ui/button'
import {
    DropdownMenu,
    DropdownMenuContent,
    DropdownMenuItem,
    DropdownMenuTrigger,
} from '@/components/ui/dropdown-menu'
import { useLaravelReactI18n } from 'laravel-react-i18n'
import { LanguagesIcon } from 'lucide-react'

interface Language {
    code: string
    name: string
    flag: string
}

const languages: Language[] = [
    { code: 'id', name: 'Indonesia', flag: '🇮🇩' },
    { code: 'en', name: 'English', flag: '🇺🇸' },
]

export const LanguageSwitcher = () => {
    const { currentLocale, setLocale, loading } = useLaravelReactI18n()

    const handleChangeLanguage = (code: string) => {
        // Update the React i18n context immediately (instant UI feedback)
        setLocale(code)

        // Update the HTML lang attribute for accessibility
        document.documentElement.lang = code

        // Persist to backend (see next section)
        // router.post('/user/preferences', { locale: code })
    }

    const currentLanguage =
        languages.find(lang => lang.code === currentLocale()) || languages[0]

    return (
        <DropdownMenu>
            <DropdownMenuTrigger asChild>
                <Button
                    variant="ghost"
                    size="sm"
                    className="gap-2"
                    disabled={loading}    // shows while translations are loading
                >
                    <span className="text-lg">{currentLanguage.flag}</span>
                    <span className="hidden sm:inline-block text-sm">
                        {currentLanguage.name}
                    </span>
                    <LanguagesIcon className="h-4 w-4 opacity-50" />
                </Button>
            </DropdownMenuTrigger>
            <DropdownMenuContent align="end" className="w-40">
                {languages.map(lang => (
                    <DropdownMenuItem
                        key={lang.code}
                        onClick={() => handleChangeLanguage(lang.code)}
                        className={`cursor-pointer ${
                            currentLocale() === lang.code ? 'bg-accent' : ''
                        }`}
                    >
                        <span className="text-lg mr-2">{lang.flag}</span>
                        <span>{lang.name}</span>
                    </DropdownMenuItem>
                ))}
            </DropdownMenuContent>
        </DropdownMenu>
    )
}

export default LanguageSwitcher

Three things from useLaravelReactI18n() being used here:

currentLocale() — returns the active locale code (e.g., 'en' or 'id')
setLocale(code) — switches the locale in React's context, causing all t() calls to re-render
loading — true while new locale files are being loaded; use it to disable the button

Step 8: Persist Locale Across Sessions

setLocale() only updates the current browser session. If the user refreshes the page, the locale reverts to whatever the server sends. To make it stick, you need to save it on the backend.

The backend controller:

// app/Http/Controllers/UserPreferenceController.php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\App;

class UserPreferenceController extends Controller
{
    public function generalStore(Request $request)
    {
        $locale = $request->locale ?? 'id';

        // Whitelist only supported locales
        if (! in_array($locale, ['id', 'en'])) {
            $locale = 'id';
        }

        // Save to user's preferences (stored as JSON in DB)
        auth()->user()->setPreference('general', [
            'per_page' => $request->perPage,
            'locale' => $locale,
        ]);

        // Update the server-side locale for this request
        App::setLocale($locale);
        session(['locale' => $locale]);

        return redirect()->back();
    }
}

The settings page where users pick their language:

// resources/js/pages/setting/general.tsx

import { router } from '@inertiajs/react'
import { useLaravelReactI18n } from 'laravel-react-i18n'

const handleLocaleChange = (locale: string) => {
    // Update React UI immediately
    setLocale(locale)

    // Persist to backend (Inertia form submit)
    router.post('/user/preferences/general', {
        locale: locale,
        perPage: currentPerPage,
    })
}

The flow on the next page load:

Inertia request comes in
HandleInertiaRequests reads auth()->user()->getPreference('general')['locale']
That value is set on App::setLocale() AND shared as 'locale' in Inertia props
app.tsx reads it as initialLocale and passes it to LaravelReactI18nProvider
Every component using t() renders in the correct language

This means locale persists across devices — it's tied to the user account, not the browser.

Step 9: Translations in the Backend

Don't forget — your backend also generates strings. Validation error messages, journal titles, observer messages, and more. These all need to be translated too, using PHP's __() function.

Journal titles in event listeners:

// app/Listeners/CreateJournalDisposalListener.php

$journal_title = __('asset.journal.disposal_title');

// app/Listeners/PostJournalRefundLoanListener.php

$journal_title = __('refund_loan.journal.journal_title');

Validation messages in DTOs:

// app/Data/PosProductData.php (using spatie/laravel-data)

public static function rules(): array
{
    return [
        'name' => ['required', 'string', 'max:255'],
        'product_category_id' => ['required', 'exists:product_categories,id'],
        'selling_price' => ['required', 'numeric', 'min:0'],
    ];
}

public static function messages(): array
{
    return [
        'name.required' => __('product.pos.validation.name_required'),
        'name.max' => __('product.pos.validation.name_max'),
        'product_category_id.required' => __('product.pos.validation.category_required'),
        'selling_price.required' => __('product.pos.validation.selling_price_required'),
        'selling_price.numeric' => __('product.pos.validation.selling_price_numeric'),
    ];
}

Enum labels — a neat pattern for making enum values show translated labels:

// app/Enums/FiscalPeriodStatus.php

enum FiscalPeriodStatus: string
{
    case Open = 'open';
    case Closing = 'closing';
    case Closed = 'closed';

    public function label(): string
    {
        return match($this) {
            self::Open    => __('period_closing.status.open'),
            self::Closing => __('period_closing.status.closing'),
            self::Closed  => __('period_closing.status.closed'),
        };
    }
}

// app/Enums/AdjustingEntryType.php

public function label(): string
{
    return match($this) {
        self::Depreciation       => __('period_closing.adjusting_types.depreciation'),
        self::Amortization       => __('period_closing.adjusting_types.amortization'),
        self::Accrual            => __('period_closing.adjusting_types.accrual'),
        self::CurrencyRevaluation => __('period_closing.adjusting_types.currency_revaluation'),
        self::InventoryAdjustment => __('period_closing.adjusting_types.inventory_adjustment'),
        self::Other              => __('period_closing.adjusting_types.other'),
    };
}

Since App::setLocale() is called in the middleware on every request, these __() calls automatically use the user's preferred locale.

File Organization Patterns

Here's the full picture of how this app organizes translations:

lang/
  en/
    expense.php          # all expense feature strings
    invoice.php          # invoice PDF strings
    over_receipt.php     # over receipt feature strings
    general.php          # shared status labels (paid, pending, etc.)
    sidebar-menu.php     # navigation labels
    dashboard.php        # dashboard widgets
    # ... one file per feature
  id/
    expense.php          # same structure, Indonesian
    invoice.php
    over_receipt.php
    general.php
    sidebar-menu.php
    # ...
  php_en.json            # compiled output (generated by laravel-react-i18n)
  php_id.json            # compiled output

The JSON files are auto-generated from the PHP files when you run the build. You never edit them manually.

Key nesting conventions used in this codebase:

Namespace	Usage
`expense.columns.*`	Table column headers
`expense.form.*`	Form field labels, placeholders, button text
`expense.actions.*`	Action button labels
`expense.stats.*`	Statistics card labels
`expense.info.*`	Detail page info section
`expense.journal.*`	Journal-related strings

This makes it obvious where to find (or add) any string. When you're looking for the "Delete" button label on the expense page, you instinctively check expense.actions.delete.

Gotchas and Things That Will Bite You

1. The JSON files need to be regenerated after you add PHP keys

When you add a new key to lang/en/expense.php, the browser won't see it until the JSON is regenerated:

php artisan lang:export   # or just run your build
npx vite build

In development with vite dev, this usually happens automatically via the plugin. But if something seems missing, this is the first thing to check.

2. `t()` in `useMemo` needs `t` as a dependency

When you use t() inside useMemo or useCallback, always include t in the dependency array:

// Wrong - translation won't update when locale changes
const columns = useMemo(() => [
    { header: t('expense.columns.total') }
], []) // missing t!

// Correct
const columns = useMemo(() => [
    { header: t('expense.columns.total') }
], [t]) // t is stable but this is correct practice

3. Backend strings must stay in sync with the locale

When the middleware sets App::setLocale($locale), all subsequent __() calls in that request use that locale. This means if you generate a journal title or validation message, it'll be in the user's language — which is usually what you want, but be intentional about it.

4. Don't use `t()` outside of React components

The useLaravelReactI18n hook only works inside React components. If you need translations in a utility function or class, pass the t function as a parameter, or restructure to call it from a component.

5. Keys that don't exist return the key itself

If you call t('expense.form.nonexistent_key'), the library returns 'expense.form.nonexistent_key' as a string. This is fine for catching missing keys (you'll see the raw key in the UI), but don't rely on it in production — keep your key files complete.

Cheat Sheet

// Import in any React component
import { useLaravelReactI18n } from 'laravel-react-i18n'

const MyComponent = () => {
    const { t, currentLocale, setLocale, loading } = useLaravelReactI18n()

    // Basic translation
    t('expense.title')                          // -> 'Expense Data' (en) or 'Data Pengeluaran' (id)

    // Nested keys
    t('expense.form.pay_from')                  // -> 'Pay From' or 'Bayar Dari'

    // With dynamic values
    t('over_receipt.refund_form.amount_exceeds_balance', {
        max: 'Rp 500,000'
    })                                          // -> 'Amount cannot exceed remaining credit (Rp 500,000)'

    // Get current locale
    currentLocale()                             // -> 'en' or 'id'

    // Switch locale (current session only)
    setLocale('en')

    // Check if translations are loading
    loading                                     // -> boolean
}

// Laravel backend

// Basic translation (uses current App locale)
__('expense.title')                            // -> 'Expense Data' or 'Data Pengeluaran'

// With parameters
__('over_receipt.refund_form.amount_exceeds_balance', ['max' => 'Rp 500.000'])

// Set locale for a request
App::setLocale('en');

// Read locale
App::getLocale();                              // -> 'en'

// lang/en/example.php

return [
    'simple' => 'A simple string',
    'with_param' => 'Hello, :name!',
    'nested' => [
        'deeply' => [
            'key' => 'Deeply nested value',
        ],
    ],
];

// Using the above in React:
t('example.simple')                            // -> 'A simple string'
t('example.with_param', { name: 'World' })     // -> 'Hello, World!'
t('example.nested.deeply.key')                 // -> 'Deeply nested value'

That's the full picture. Once you internalize the pattern — PHP files define the strings, JSON compilation bridges them to the browser, LaravelReactI18nProvider makes them available in React, and the middleware keeps server and client in sync — the day-to-day work is just maintaining the key files in parallel.

The rule in this codebase: never hardcode a user-facing string. Every label, every toast message, every table header, every error — goes in lang/. Your future self (and your users) will thank you.

Understanding Laravel DTO: Clean Data Transfer in Modern Applications

Abd. Asis — Sat, 28 Feb 2026 01:52:55 +0000

Introduction

If you've been building Laravel applications for a while, you've probably seen this before — a controller method that does way too much:

public function store(Request $request)
{
    $validated = $request->validate([
        'contact_id'  => 'required|exists:contacts,id',
        'trans_date'  => 'required|date',
        'due_date'    => 'required|date|after_or_equal:trans_date',
        'items'       => 'required|array|min:1',
        'items.*.product_id' => 'required|exists:products,id',
        'items.*.qty' => 'required|numeric|min:0.01',
        // ... 20 more rules
    ]);

    // Normalize some fields
    if ($validated['currency_id'] === '') {
        $validated['currency_id'] = null;
    }

    // Compute totals
    $validated['amount'] = collect($validated['items'])->sum('amount');

    // Create the record
    $sale = Sale::create($validated);

    // Log the action
    activity()->on($sale)->log('created sale order');

    return redirect()->route('sale-orders.index');
}

This controller knows too much. It validates, normalizes, computes totals, persists, and logs — all in one method. When you need to create a sale order from a different place (say, a console command or a webhook), you copy-paste the whole block. When a business rule changes, you hunt through controllers to find every place that touched the same data.

This is exactly the problem DTOs (Data Transfer Objects) solve.

A DTO is a simple PHP object whose entire job is to carry structured, typed data from one layer of your application to another. It has no behavior beyond holding that data. No database access. No HTTP knowledge. Just a clean, typed container.

In a modern Laravel application, DTOs act as the contract between layers: the HTTP layer passes a DTO to the service layer, the service passes it to an action, and the action uses it to interact with the database. Every layer speaks the same language — the DTO.

What is a DTO?

A Data Transfer Object is an object that carries data between processes or application layers. The term comes from Martin Fowler's Patterns of Enterprise Application Architecture, but the concept is simpler than the name suggests: it's just a PHP class with public properties and no business logic.

DTO vs Request vs Model vs Value Object

These four things are often confused. Here's how they differ:

Concept	Purpose	Has Logic?	Layer
Form Request	HTTP validation only	Validation rules	HTTP layer
DTO	Carry typed data across layers	Minimal / none	Any
Model	Represent + persist a database row	Relationships, accessors	Data layer
Value Object	Represent a concept with identity	Equality rules	Domain layer

A Request knows about HTTP. A Model knows about your database. A Value Object enforces business rules around a single concept (like a monetary amount or an email address). A DTO knows nothing — it just holds data. That's its strength.

When to use a DTO

Passing validated HTTP input into a service or action
Returning structured data from a repository or report service
Transforming complex API responses into typed PHP objects
Carrying configuration data through a multi-step process

When NOT to use a DTO

Simple CRUD with a single field — a DTO adds ceremony with no benefit
Data that never leaves a single method
Replacing Eloquent models when the model is already the right tool
As a replacement for Value Objects when identity/equality semantics matter

Implementing a DTO in Laravel

Let's start with a plain PHP DTO — no packages, no magic, just a class with constructor property promotion (PHP 8+).

Manual DTO

<?php

namespace App\Data;

class SaleOrderData
{
    public function __construct(
        public readonly int $contact_id,
        public readonly string $trans_date,
        public readonly string $due_date,
        public readonly ?int $warehouse_id,
        public readonly bool $include_tax,
        public readonly float $shipping_cost,
        public readonly array $items,
        public readonly array $additional_discounts = [],
    ) {}
}

readonly properties make the DTO immutable after construction — once you build it from the request, nothing downstream can accidentally mutate it. That's exactly what you want from a data carrier.

Constructor-based validation and typing

The constructor itself enforces your type contract. If someone tries to pass a string where contact_id expects an int, PHP 8 will throw a TypeError immediately — not a mysterious null reference ten method calls later.

You can add a static factory to keep the controller clean:

public static function fromArray(array $data): self
{
    return new self(
        contact_id:           (int)   $data['contact_id'],
        trans_date:                   $data['trans_date'],
        due_date:                     $data['due_date'],
        warehouse_id:         isset($data['warehouse_id'])
                                ? (int) $data['warehouse_id'] : null,
        include_tax:          (bool)  ($data['include_tax'] ?? false),
        shipping_cost:        (float) ($data['shipping_cost'] ?? 0),
        items:                        $data['items'],
        additional_discounts:         $data['additional_discounts'] ?? [],
    );
}

Usage in Controller and Service

The controller's only job is to validate the raw HTTP input and hand a typed DTO to the service:

// SaleOrderController.php

public function store(Request $request): RedirectResponse
{
    Gate::authorize('buat pemesanan');

    $dto = SaleOrderData::fromArray(
        $request->validate($this->validationRules())
    );

    $this->service->create($dto);

    return redirect()->route('sale-orders.index')
        ->with('success', __('sale_order.store_success'));
}

The service orchestrates the work — it doesn't care where the data came from:

// SaleOrderService.php

public function create(SaleOrderData $data): Sale
{
    return DB::transaction(function () use ($data) {
        $sale = $this->createAction->execute($data);
        $this->downPaymentAction->execute($sale);

        return $sale;
    });
}

The action is where the actual business logic lives:

// CreateSaleOrderAction.php

public function execute(SaleOrderData $data): Sale
{
    $payload = $data->toArray();

    // Resolve currency from contact if not provided
    if (empty($payload['currency_id'])) {
        $contact = Contact::with('currency')->find($data->contact_id);
        $payload['currency_id'] = $contact?->currency_id
            ?? Currency::where('code', 'IDR')->value('id');
    }

    // Compute derived totals from items
    $payload['amount'] = collect($data->items)->sum('amount');

    $sale = $this->repository->create($payload);

    SaleOrderCreatedEvent::dispatch($sale);

    activity()
        ->performedOn($sale)
        ->log('membuat data pemesanan penjualan ' . $sale->transaction_number);

    return $sale;
}

Notice how clean each layer is. The controller doesn't compute totals. The service doesn't validate. The action doesn't know about HTTP. Each layer has a single, clear responsibility.

Using DTO with Form Requests

Form Requests and DTOs are complementary, not competing. The Form Request handles HTTP-level concerns (authorization, validation rules, error formatting). The DTO takes the validated data and carries it forward.

// StoreSaleOrderRequest.php

class StoreSaleOrderRequest extends FormRequest
{
    public function authorize(): bool
    {
        return Gate::check('buat pemesanan');
    }

    public function rules(): array
    {
        return [
            'contact_id'         => ['required', 'integer', 'exists:contacts,id'],
            'trans_date'         => ['required', 'date'],
            'due_date'           => ['required', 'date', 'after_or_equal:trans_date'],
            'warehouse_id'       => ['nullable', 'integer', 'exists:warehouses,id'],
            'items'              => ['required', 'array', 'min:1'],
            'items.*.product_id' => ['required', 'exists:products,id'],
            'items.*.qty'        => ['required', 'numeric', 'min:0.01'],
            'items.*.price'      => ['required', 'numeric', 'min:0'],
        ];
    }
}

Then in the controller, transform it into a DTO immediately:

public function store(StoreSaleOrderRequest $request): RedirectResponse
{
    $dto = SaleOrderData::fromArray($request->validated());

    $this->service->create($dto);

    return redirect()->route('sale-orders.index')
        ->with('success', __('sale_order.store_success'));
}

Why combine them? The Form Request is thrown away after the controller. The DTO travels through your entire application stack. By converting early, every layer below the controller works with a typed, predictable object — not a raw array that might have null, an empty string, or a missing key depending on what the user submitted.

Advanced Approach

Immutable DTOs

The readonly keyword in PHP 8.1+ makes immutability effortless:

class PosTransactionData
{
    public function __construct(
        public readonly int $contact_id,
        public readonly ?string $discount_type,
        public readonly float $discount_amount,
        public readonly array $items,
        public readonly array $payments,
    ) {}
}

Once constructed, $dto->contact_id = 5 throws an error. This is a strong guarantee: any layer that receives the DTO knows the data hasn't been altered by a layer above it.

Using spatie/laravel-data

For production applications with many DTOs, spatie/laravel-data is worth knowing. It combines validation, casting, and transformation into a single class, eliminating a lot of boilerplate. This project uses it extensively:

use Spatie\LaravelData\Data;
use Spatie\LaravelData\Attributes\Validation\Required;

class PosProductData extends Data
{
    public function __construct(
        #[Required, Max(255)]
        public string $name,

        #[Required, Exists('product_categories', 'id')]
        public int $product_category_id,

        #[Required, Numeric, Min(0)]
        public float $selling_price,
    ) {}
}

The validateAndCreate() static method on a spatie/laravel-data class validates the input and builds the DTO in one call:

$dto = SaleOrderData::validateAndCreate($request->all());

No separate Form Request needed — the DTO carries the validation rules. You also get built-in support for casting nested arrays into typed collections, transforming the DTO back to an array, and pipeline hooks for data normalization.

Real-World Example: Creating a POS Transaction

Let's see what life looks like before and after DTOs using a real feature from a Point-of-Sale system.

Before: Everything in the controller

// PosController.php — the old way

public function checkout(Request $request)
{
    // Validation buried in the controller
    $request->validate([
        'contact_id'              => 'required|exists:contacts,id',
        'items'                   => 'required|array|min:1',
        'items.*.product_id'      => 'required|exists:products,id',
        'items.*.quantity'        => 'required|numeric|gt:0',
        'items.*.unit_price'      => 'required|numeric|min:0',
        'payments'                => 'required|array|min:1',
        'payments.*.amount'       => 'required|numeric|gt:0',
        'payments.*.payment_method_id' => 'required|exists:payment_methods,id',
    ]);

    // Normalize discount type inline
    $discount_type = $request->discount_type === ''
        ? null : $request->discount_type;

    // Compute totals
    $subtotal = collect($request->items)->sum(fn ($i) => $i['unit_price'] * $i['quantity']);

    // Create sale record
    $sale = Sale::create([
        'contact_id'      => $request->contact_id,
        'discount_type'   => $discount_type,
        'discount_amount' => $request->discount_amount ?? 0,
        'amount'          => $subtotal,
        'status'          => 'open',
        'type'            => 'Faktur Penjualan',
        'pos_session_id'  => $request->session_id,
    ]);

    // Create items
    foreach ($request->items as $item) {
        $sale->items()->create([
            'product_id'  => $item['product_id'],
            'quantity'    => $item['quantity'],
            'unit_price'  => $item['unit_price'],
            'total_price' => $item['unit_price'] * $item['quantity'],
        ]);
    }

    // Process payments
    foreach ($request->payments as $payment) {
        // ... more logic here
    }

    activity()->on($sale)->log('POS transaction');

    return response()->json(['success' => true, 'sale_id' => $sale->id]);
}

This controller is doing five different jobs. Testing it requires a full HTTP request. Reusing any part of it from a scheduled command is impossible.

After: Clean separation with DTO

Step 1 — the DTO carries all the transaction data with full typing:

// app/Data/PosTransactionData.php

class PosTransactionData extends Data
{
    public function __construct(
        public int $contact_id,
        public ?string $discount_type,
        public float $discount_amount,
        public ?int $discount_account,
        public ?string $notes,
        public array $items,
        public array $payments,
    ) {}

    public static function rules(): array
    {
        return [
            'contact_id'                   => ['required', 'exists:contacts,id'],
            'discount_type'                => ['nullable', 'in:percentage,amount'],
            'items'                        => ['required', 'array', 'min:1'],
            'items.*.product_id'           => ['required', 'exists:products,id'],
            'items.*.quantity'             => ['required', 'numeric', 'gt:0'],
            'items.*.unit_price'           => ['required', 'numeric', 'min:0'],
            'payments'                     => ['required', 'array', 'min:1'],
            'payments.*.payment_method_id' => ['required', 'exists:payment_methods,id'],
            'payments.*.amount'            => ['required', 'numeric', 'gt:0'],
        ];
    }

    public static function messages(): array
    {
        return [
            'items.min'            => 'Minimal 1 item harus ditambahkan.',
            'payments.min'         => 'Minimal 1 pembayaran harus ditambahkan.',
            'payments.*.amount.gt' => 'Jumlah pembayaran harus lebih dari 0.',
        ];
    }
}

Step 2 — the controller becomes trivially thin:

// PosController.php

public function checkout(PosSession $session, Request $request): JsonResponse
{
    $dto = PosTransactionData::validateAndCreate($request->all());
    $sale = $this->posService->createTransaction($session, $dto);

    return response()->json(['success' => true, 'sale_id' => $sale->id]);
}

Step 3 — the service orchestrates the flow:

// PosService.php

public function createTransaction(PosSession $session, PosTransactionData $data): Sale
{
    return $this->create_transaction_action->execute($session, $data);
}

Step 4 — the action has the actual business logic:

// CreatePosTransactionAction.php

public function execute(PosSession $session, PosTransactionData $data): Sale
{
    $sale = Sale::create([
        'contact_id'      => $data->contact_id,
        'discount_type'   => $data->discount_type,
        'discount_amount' => $data->discount_amount,
        'pos_session_id'  => $session->id,
        'amount'          => collect($data->items)->sum(
            fn ($i) => $i['unit_price'] * $i['quantity']
        ),
        'status'          => 'open',
        'type'            => 'Faktur Penjualan',
    ]);

    $this->createItems($sale, $data->items);
    $this->processPayments($sale, $data->payments);

    activity()
        ->performedOn($sale)
        ->log('POS transaction created: ' . $sale->transaction_number);

    return $sale;
}

Now consider what you gained:

The controller has no idea how a POS transaction works — it just validates and delegates
The service can be called from anywhere: a console command, a webhook handler, a test
The action can be unit tested by passing a PosTransactionData directly — no HTTP stack needed
The DTO is the documentation: anyone reading PosTransactionData knows exactly what a POS transaction requires

This is the actual structure used in this project. The PosService receives a PosTransactionData, passes it to CreatePosTransactionAction, which does the work. The controller at the top stays blissfully ignorant of the details.

Conclusion

DTOs are not a silver bullet, and they're not always necessary. For a two-field form updating a user's name, a DTO adds noise. But the moment your data crosses multiple layers — from HTTP to service to action to repository — a DTO pays for itself immediately.

Key takeaways:

A DTO is a promise. When CreateSaleOrderAction::execute() accepts a SaleOrderData, every caller knows exactly what to provide. No more checking if $request->get('contact_id') is present, or if the array key items exists. The DTO contract is enforced at construction time.

A DTO enables testing. You can instantiate a PosTransactionData in a test without touching HTTP, without a live request, without middleware. Just build the object and pass it to the action.

A DTO decouples your layers. The controller knows about HTTP. The model knows about the database. The DTO sits between them and knows about neither. That separation is what makes your codebase maintainable when it grows from 10 routes to 150.

A DTO makes refactoring safe. If you add a required field to SaleOrderData, PHP will immediately tell you every call site that needs updating. Try doing that with an associative array.

The pattern Controller -> Service -> Action -> Repository, with DTOs flowing between them, is what keeps a large codebase from turning into the tangled mess we started with. You get thin controllers, focused actions, and data structures that document themselves.

Start with a manual readonly class. Add spatie/laravel-data when you need validation built in. Either way, the discipline of giving your data a proper home — rather than scattering raw arrays and $request->get() calls across your codebase — is one of the highest-leverage habits you can build as a Laravel developer.

Stack: PHP 8.4 | Laravel 12 | spatie/laravel-data

Implementasi Brick Money di Laravel: Studi Kasus Aplikasi Akuntansi

Abd. Asis — Sat, 28 Feb 2026 01:38:42 +0000

Panduan lengkap menggunakan library brick/money untuk kalkulasi keuangan presisi tinggi di Laravel, berdasarkan implementasi nyata di aplikasi akuntansi multi-currency.

Daftar Isi

Mengapa Bukan Float?
Instalasi dan Setup
Konsep Dasar: Money, RationalMoney, dan Context
Pola 1: Kalkulasi Sederhana dengan Money
Pola 2: Multi-Step Calculation dengan RationalMoney
Pola 3: Multi-Currency Support
Pola 4: Konversi ke/dari Database
Pola 5: Integrasi dengan Spatie Laravel Data (DTO)
Anti-Pattern yang Harus Dihindari
Referensi File Project

Mengapa Bukan Float?

Float di PHP (dan hampir semua bahasa) memiliki masalah presisi yang terkenal:

// PHP floating point surprise
echo 0.1 + 0.2; // 0.30000000000000004

// Dalam konteks uang: Rp 100.000 x 10.5% pajak
$harga = 100000;
$pajak = $harga * 10.5 / 100;
// Bisa menghasilkan: 10500.000000000002

Di aplikasi akuntansi, selisih 1 rupiah pun bisa menyebabkan jurnal tidak balance. brick/money menyelesaikan ini dengan menggunakan arbitrary-precision arithmetic yang menjamin hasil kalkulasi selalu tepat.

Instalasi dan Setup

composer require brick/money

Tidak perlu konfigurasi tambahan — library ini standalone dan tidak perlu service provider.

Konsep Dasar

brick/money memiliki tiga konsep utama:

Money — Nilai Uang yang Sudah Dibulatkan

use Brick\Money\Money;

$harga = Money::of(150000, 'IDR');        // Rp 150.000
$diskon = Money::of(25000, 'IDR');         // Rp 25.000
$total = $harga->minus($diskon);           // Rp 125.000

Money selalu memiliki jumlah desimal yang pasti sesuai mata uangnya (IDR = 0 desimal, USD = 2 desimal).

RationalMoney — Presisi Tak Terbatas untuk Kalkulasi Bertingkat

use Brick\Money\Money;
use Brick\Math\RoundingMode;
use Brick\Money\Context\DefaultContext;

// Mulai dengan rational untuk menghindari rounding error di tengah
$subtotal = Money::of(333333, 'IDR')->toRational();
$pajak = $subtotal->multipliedBy('11')->dividedBy('100');

// Baru bulatkan di akhir
$pajakFinal = $pajak->to(new DefaultContext(), RoundingMode::HALF_UP);

RationalMoney menyimpan angka sebagai pecahan (numerator/denominator), sehingga tidak ada presisi yang hilang sampai Anda memutuskan untuk membulatkan.

Context — Aturan Pembulatan per Mata Uang

use Brick\Money\Context\CustomContext;

// IDR: 0 desimal
$contextIDR = new CustomContext(0);
$money = Money::of(1500.7, 'IDR', $contextIDR); // Error! Harus dibulatkan dulu

// USD: 2 desimal (default ISO)
$usd = Money::of(12.50, 'USD'); // OK, 2 desimal adalah default USD

Pola 1: Kalkulasi Sederhana

Use case: Menghitung saldo penjualan setelah pembayaran dan retur.

// app/Services/OverReceiptService.php

use Brick\Money\Money;

public function calculateBalance(Sale $sale): Money
{
    $sale_amount    = Money::of($sale->amount, 'IDR');
    $payment_amount = Money::of($sale->payments->sum('amount'), 'IDR');
    $return_amount  = Money::of($sale->returns->sum('amount'), 'IDR');

    return $sale_amount
        ->minus($payment_amount)
        ->minus($return_amount);
}

public function hasOverpayment(Money $balance): bool
{
    return $balance->isNegative();
}

public function getOverReceiptAmount(Money $balance): int
{
    return $balance->abs()->getAmount()->toInt();
}

Mengapa ini penting?

Tanpa brick/money, kode ini mungkin ditulis:

// JANGAN seperti ini
$balance = $sale->amount - $payments - $returns;

Terlihat sederhana, tapi jika amount dan payments adalah float, hasil pengurangan bisa mengandung error presisi yang membuat $balance == 0 gagal meskipun seharusnya nol.

Dengan brick/money, Anda bisa yakin:

$balance->isZero();     // Tepat
$balance->isNegative(); // Tepat
$balance->isPositive(); // Tepat

Pola 2: Multi-Step Calculation dengan RationalMoney

Use case: Menghitung total Purchase Order dengan item, pajak, diskon persentase, biaya pengiriman, dan biaya tambahan.

Ini adalah pola paling canggih di project ini — semua kalkulasi dilakukan dalam domain RationalMoney, dan pembulatan hanya terjadi satu kali di akhir.

// app/Support/PurchaseOrderCalculator.php

use Brick\Math\RoundingMode;
use Brick\Money\Context\DefaultContext;
use Brick\Money\Money;

public function calculate(array $items, array $options): array
{
    // 1. Inisialisasi akumulator dalam RationalMoney
    $subtotalRational      = Money::of('0', 'IDR')->toRational();
    $totalTaxRational      = Money::of('0', 'IDR')->toRational();
    $totalDiscountRational = Money::of('0', 'IDR')->toRational();
    $totalFeesRational     = Money::of('0', 'IDR')->toRational();

    // 2. Akumulasi per-item TANPA pembulatan
    foreach ($items as $item) {
        $amount = $item['quantity'] * $item['unit_price'];
        $tax    = $amount * ($item['tax_rate'] / 100);

        $subtotalRational = $subtotalRational
            ->plus(Money::of($amount, 'IDR')->toRational());
        $totalTaxRational = $totalTaxRational
            ->plus(Money::of($tax, 'IDR')->toRational());
    }

    // 3. Bulatkan subtotal untuk basis kalkulasi persentase
    $subtotal = $subtotalRational
        ->to(new DefaultContext(), RoundingMode::HALF_UP);

    // 4. Hitung diskon persentase di RationalMoney
    foreach ($discounts as $discount) {
        if ($discount['type'] === 'percentage') {
            $discountRational = $subtotal->toRational()
                ->multipliedBy($discount['value'])
                ->dividedBy('100');
        } else {
            $discountRational = Money::of($discount['value'], 'IDR')
                ->toRational();
        }
        $totalDiscountRational = $totalDiscountRational
            ->plus($discountRational);
    }

    // 5. Grand total — semua operasi di RationalMoney
    $shippingCost = Money::of($options['shipping_cost'] ?? 0, 'IDR');

    $grandTotalRational = $subtotalRational
        ->plus($totalTaxRational)
        ->minus($totalDiscountRational)
        ->plus($shippingCost->toRational())
        ->plus($totalFeesRational);

    // 6. Pembulatan HANYA di akhir
    $grandTotal = $grandTotalRational
        ->to(new DefaultContext(), RoundingMode::HALF_UP);
    $totalTax = $totalTaxRational
        ->to(new DefaultContext(), RoundingMode::HALF_UP);

    return [
        'grand_total' => $grandTotal->getAmount()->__toString(),
        'total_tax'   => $totalTax->getAmount()->__toString(),
    ];
}

Mengapa RationalMoney, bukan Money biasa?

Bayangkan 100 item masing-masing Rp 33.333 dengan pajak 11%:

Money: Setiap pajak per-item dibulatkan → 33333 * 11% = 3666.63 → 3667 → total 100 item = 366.700
RationalMoney: Pajak per-item tetap pecahan → total = 366.663 → dibulatkan sekali = 366.663 → 366.663

Selisih kecil per-item, tapi terakumulasi di ratusan item.

Pola 3: Multi-Currency Support

Use case: Konversi Purchase Order dari mata uang supplier (USD/EUR) ke IDR.

// Currency model menyediakan factory method
// app/Models/Currency.php

use Brick\Money\Context\CustomContext;
use Brick\Money\Money;

public function toMoney(float|int|null $amount): Money
{
    $rounded_amount = round($amount ?? 0, $this->decimal_places);
    $context = new CustomContext($this->decimal_places);

    try {
        return Money::of($rounded_amount, $this->code, $context);
    } catch (\Brick\Money\Exception\UnknownCurrencyException $e) {
        // Untuk kode mata uang kustom yang tidak ada di ISO
        return Money::of($rounded_amount, 'XXX', $context);
    }
}

Penggunaan di controller untuk konversi dokumen:

// app/Http/Controllers/PurchaseOrderController.php

use Brick\Math\RoundingMode;
use Brick\Money\Money;

// Konversi item PO ke invoice dengan kalkulasi presisi
$items = collect($validated['items'])->map(function ($item) use ($currency_code) {
    return [
        'unit_price'  => Money::of($item['unit_price'], $currency_code)
            ->getAmount()
            ->toFloat(),
        'total_price' => Money::of($item['unit_price'], $currency_code)
            ->multipliedBy($item['remaining_invoice_quantity'], RoundingMode::HALF_UP)
            ->getAmount()
            ->toFloat(),
    ];
});

Poin penting: RoundingMode::HALF_UP wajib dispecify saat multipliedBy() atau dividedBy() karena hasilnya bisa mengandung desimal yang lebih panjang dari context mata uang. Tanpa rounding mode, brick/money akan throw exception.

Pola 4: Konversi ke/dari Database

Menyimpan ke Database

// Dari Money object ke integer (untuk kolom bigInteger)
$debit = Money::of($sale->amount, 'IDR')
    ->getAmount()
    ->toInt();

// Dari Money object ke float (untuk kolom decimal)
$unit_price = Money::of($item['unit_price'], 'USD')
    ->getAmount()
    ->toFloat();

// Dari RationalMoney ke string (untuk presisi penuh)
$grand_total = $grandTotalRational
    ->to(new DefaultContext(), RoundingMode::HALF_UP)
    ->getAmount()
    ->__toString();

Membaca dari Database

// Dari kolom decimal — langsung pakai Money::of()
$amount = Money::of($model->amount, 'IDR');

// Dari kolom bigInteger (minor units) — pakai Money::ofMinor()
$amount = Money::ofMinor($model->amount_minor, 'IDR');

Jurnal Akuntansi

// app/Listeners/PostSaleJournalListener.php

// Debit piutang dagang
$ar_debit = Money::of($sale->amount, 'IDR')->getAmount()->toInt();

// Credit pendapatan per item
foreach ($sale->items as $item) {
    $revenue_credit = Money::of($item['total_price'], 'IDR')
        ->getAmount()
        ->toInt();
}

// Debit HPP dan credit persediaan
$hpp_debit = Money::of($item_cogs, 'IDR')->getAmount()->toInt();
$inventory_credit = Money::of($item_cogs, 'IDR')->getAmount()->toInt();

Dengan brick/money, jurnal yang diposting dijamin balance karena setiap konversi melalui presisi yang terkontrol.

Pola 5: Integrasi dengan Spatie Laravel Data (DTO)

DTO menerima nilai mentah (int/float), dan konversi ke Money terjadi di layer Service/Action:

// app/Data/TransferData.php
class TransferData extends Data
{
    public function __construct(
        public int $amount,  // Minor units (integer)
        // ...
    ) {}

    public static function rules(): array
    {
        return [
            'amount' => ['required', 'integer'],
        ];
    }
}

// Di Service layer
class TransferService
{
    public function execute(TransferData $data): void
    {
        $amount = Money::ofMinor($data->amount, 'IDR');

        // Kalkulasi dengan presisi penuh
        $fee = $amount->multipliedBy('0.01', RoundingMode::HALF_UP);
        $net = $amount->minus($fee);

        // Simpan
        Transfer::query()->create([
            'amount'     => $net->getMinorAmount()->toInt(),
            'fee_amount' => $fee->getMinorAmount()->toInt(),
        ]);
    }
}

Prinsip: DTO hanya transport data. Logika uang ada di Service/Action.

Anti-Pattern yang Harus Dihindari

1. Aritmatika PHP pada Nilai Uang

// SALAH — floating point error
$total = $harga * $quantity;
$pajak = $total * 11 / 100;
$grand = $total + $pajak - $diskon;

// BENAR — brick/money
$total = Money::of($harga, 'IDR')
    ->multipliedBy($quantity, RoundingMode::HALF_UP);
$pajak = $total->toRational()
    ->multipliedBy('11')->dividedBy('100')
    ->to(new DefaultContext(), RoundingMode::HALF_UP);
$grand = $total->plus($pajak)->minus(Money::of($diskon, 'IDR'));

2. Lupa RoundingMode

// SALAH — Exception jika hasil tidak bisa direpresentasikan
$result = $money->multipliedBy(1.5);

// BENAR — selalu specify RoundingMode
$result = $money->multipliedBy(1.5, RoundingMode::HALF_UP);

3. Mencampur Mata Uang

// SALAH — Exception: cannot add different currencies
$idr = Money::of(100000, 'IDR');
$usd = Money::of(10, 'USD');
$total = $idr->plus($usd); // MoneyMismatchException!

// BENAR — konversi dulu ke mata uang yang sama
$rate = $currency->getRateForDate();
$usdInIdr = $usd->multipliedBy($rate, RoundingMode::HALF_UP);
// Tapi ini tetap error karena currency code berbeda!
// Solusi: buat ulang sebagai IDR
$usdConverted = Money::of(
    $usd->getAmount()->toFloat() * $rate,
    'IDR'
);
$total = $idr->plus($usdConverted);

4. Menyimpan Float di Database untuk Uang

// KURANG IDEAL — float bisa kehilangan presisi
$table->float('amount');
$table->double('amount');

// LEBIH BAIK — decimal dengan presisi eksplisit
$table->decimal('amount', 20, 2);

// PALING BAIK — integer minor units
$table->bigInteger('amount'); // Simpan dalam satuan terkecil (sen/rupiah)

5. Membulatkan di Setiap Langkah

// SALAH — rounding error terakumulasi
foreach ($items as $item) {
    $tax = Money::of($item->price, 'IDR')
        ->multipliedBy('0.11', RoundingMode::HALF_UP); // Bulatkan per item
    $totalTax = $totalTax->plus($tax);
}

// BENAR — akumulasi di RationalMoney, bulatkan sekali
foreach ($items as $item) {
    $tax = Money::of($item->price, 'IDR')
        ->toRational()
        ->multipliedBy('11')
        ->dividedBy('100');
    $totalTaxRational = $totalTaxRational->plus($tax);
}
$totalTax = $totalTaxRational->to(new DefaultContext(), RoundingMode::HALF_UP);

Cheat Sheet

use Brick\Money\Money;
use Brick\Money\Context\DefaultContext;
use Brick\Money\Context\CustomContext;
use Brick\Math\RoundingMode;

// Buat Money
$m = Money::of(100000, 'IDR');
$m = Money::ofMinor(10000000, 'IDR');     // Dari minor units

// Aritmatika
$m->plus(Money::of(5000, 'IDR'));          // Tambah
$m->minus(Money::of(5000, 'IDR'));         // Kurang
$m->multipliedBy(2, RoundingMode::HALF_UP); // Kali
$m->dividedBy(3, RoundingMode::HALF_UP);   // Bagi

// RationalMoney untuk presisi
$r = $m->toRational();
$r->multipliedBy('11')->dividedBy('100');
$final = $r->to(new DefaultContext(), RoundingMode::HALF_UP);

// Konversi
$m->getAmount()->toInt();                   // Ke integer
$m->getAmount()->toFloat();                 // Ke float
$m->getMinorAmount()->toInt();              // Ke minor units (int)
$m->getAmount()->__toString();              // Ke string

// Perbandingan
$m->isZero();
$m->isPositive();
$m->isNegative();
$m->isEqualTo(Money::of(100000, 'IDR'));
$m->isGreaterThan(Money::of(50000, 'IDR'));
$m->isLessThan(Money::of(200000, 'IDR'));

// Custom decimal places
$context = new CustomContext(0);  // 0 desimal (IDR)
$m = Money::of(100000, 'IDR', $context);

Livewire Datatables: Cara Nampilkan Data di Livewire ke Datatable

Abd. Asis — Fri, 20 May 2022 01:44:58 +0000

Pada kesempatan kali ini selesai membuat sebuah tutorial bagaimana cara menggunakan datatable di livewire, untuk tutorialnya silahkan baca selengkapnya di link berikut ini

Livewire Datatable: Menampilkan Data ke Datatable

Tutorial Cara Memasang Sentry Monitoring pada Laravel

Abd. Asis — Tue, 17 May 2022 13:29:30 +0000

Pada postingan kali ini aku akan berbagi bagaimana cara memasang sentry error monitoring pada laravel sebelumnya kenalan dulu apa itu sentry

Sentry lebih dari software untuk monitoring error. Sentry juga merupakan software yang dapat digunakan untuk performance monitoring. Platform Sentry dapat membantu developer dalam mendiagnosis, memperbaiki dan mengoptimalkan kenerja kode yang telah dibuat. Dengan Sentry, developer dapat menghemat waktu dan energi. Saat ini, Sentry mendukung lebih dari 30 bahasa pemrograman seperti PHP, Go, Python, Javascript dan masih banyak lagi.

untuk tutorial integrasi dengan Laravel kamu bisa baca disini yaa
Tutorial Memasang Sentry Monitoring untuk Laravel Project

Membuat Desktop Notifikasi di Laravel 9

Abd. Asis — Sun, 15 May 2022 05:22:52 +0000

Selamat siang teman-teman pada hari ini aku mempelajari cara membuat desktop notifikasi di laravel 9 dan artikelnya sudah aku tulis di platform yang sedang aku kembangkan, jika teman-teman penasaran ingin membaca artikelnya silahkan langsung mampir ke sini ya

Tutorial Membuat Desktop Notifikasi pada Laravel

Cara Membuat Datatable Di Livewire

Abd. Asis — Thu, 25 Feb 2021 08:31:22 +0000

DEV Community: Abd. Asis

Laravel Multilang with Inertia + React: A Real-World Guide

Table of Contents

Why Multilang is Trickier with Inertia

The Stack

Step 1: Install laravel-react-i18n

Step 2: Wire Up the Provider in app.tsx

Step 3: Pass Locale from Laravel to React

Step 4: Structure Your Translation Files

Step 5: Use Translations in React Components

Step 6: Dynamic Values in Translations

Step 7: Build a Language Switcher

Step 8: Persist Locale Across Sessions

Step 9: Translations in the Backend

File Organization Patterns

Gotchas and Things That Will Bite You

1. The JSON files need to be regenerated after you add PHP keys

2. t() in useMemo needs t as a dependency

3. Backend strings must stay in sync with the locale

4. Don't use t() outside of React components

5. Keys that don't exist return the key itself

Cheat Sheet

Understanding Laravel DTO: Clean Data Transfer in Modern Applications

Introduction

What is a DTO?

DTO vs Request vs Model vs Value Object

When to use a DTO

When NOT to use a DTO

Implementing a DTO in Laravel

Manual DTO

Constructor-based validation and typing

Usage in Controller and Service

Using DTO with Form Requests

Advanced Approach

Immutable DTOs

Using spatie/laravel-data

Real-World Example: Creating a POS Transaction

Before: Everything in the controller

After: Clean separation with DTO

Conclusion

Implementasi Brick Money di Laravel: Studi Kasus Aplikasi Akuntansi

Daftar Isi

Mengapa Bukan Float?

Instalasi dan Setup

Konsep Dasar

Money — Nilai Uang yang Sudah Dibulatkan

RationalMoney — Presisi Tak Terbatas untuk Kalkulasi Bertingkat

Context — Aturan Pembulatan per Mata Uang

Pola 1: Kalkulasi Sederhana

Pola 2: Multi-Step Calculation dengan RationalMoney

Pola 3: Multi-Currency Support

Pola 4: Konversi ke/dari Database

Menyimpan ke Database

Membaca dari Database

Jurnal Akuntansi

Pola 5: Integrasi dengan Spatie Laravel Data (DTO)

Anti-Pattern yang Harus Dihindari

1. Aritmatika PHP pada Nilai Uang

2. Lupa RoundingMode

3. Mencampur Mata Uang

4. Menyimpan Float di Database untuk Uang

5. Membulatkan di Setiap Langkah

Cheat Sheet

Livewire Datatables: Cara Nampilkan Data di Livewire ke Datatable

Tutorial Cara Memasang Sentry Monitoring pada Laravel

Membuat Desktop Notifikasi di Laravel 9

Cara Membuat Datatable Di Livewire

2. `t()` in `useMemo` needs `t` as a dependency

4. Don't use `t()` outside of React components