Fix form state management: use defaultValues with reset instead of values

[mnindrazaka]

Summary

This PR fixes form state management across multiple controllers by switching from the values option to defaultValues in useForm() initialization, and adding explicit form.reset() calls when data loads. This prevents form state from becoming out of sync with async data updates.

Key Changes

• RentalCheckoutFormView: Refactored cart sheet visibility logic from two separate useEffect hooks into a single derived state variable (isCartSheetVisible). This eliminates the flash of the sheet opening before closing on the frame before effects run.
• All Update Controllers (Budget, Calculation, Category, Coupon, Expense, Material, Product, RentalCheckin, RentalCheckout, StockCheck, Supplier, Table, Ticket, Transaction, Variant, Wallet):
  • Changed useForm({ values: state.values, ... }) to useForm({ defaultValues: state.values, ... })
  • Added useEffect hook that calls form.reset(state.values) when state.type === 'loaded'

Implementation Details

The change from values to defaultValues + explicit reset() is the correct pattern for react-hook-form when dealing with async data. The values option causes the form to be controlled by external state on every render, which can lead to:

• Form state becoming stale when async updates occur
• Difficulty tracking dirty state
• Unexpected behavior with field validation

By using defaultValues with explicit reset() calls, the form maintains its own state while still synchronizing when data loads, providing better UX and more predictable behavior.

The RentalCheckoutFormView refactoring improves performance and UX by deriving the sheet visibility state during render rather than using effects, preventing the visual flash that occurs when effects run after the initial render.

https://claude.ai/code/session_019Y4KcC3TX7Z2UCBnbtBQYz

[mnindrazaka]

Good catch — there was actually a real bug this exposed: submitError -> SUBMIT_CANCEL re-enters type: 'loaded' without a new fetch, so the effect was re-firing on that transition too. If someone kept editing after a failed submit and then cancelled, their newer edits got reset back to the stale submitted values.

Applied via !form.formState.isDirty rather than a literal "form is empty" check, since RHF's isDirty is the idiomatic way to express "hasn't diverged from what was last set" and holds up across forms where an empty field isn't a meaningful signal (e.g. WalletForm's balance/booleans). Now the reset only fires on the initial post-fetch fill and never again once the user has touched anything, across all 17 update controllers.

---

Generated by Claude Code