Refactor: rewrite PricingForm

[shubhmjain30]

PricingForm component used in the new config-driven pricing configuration has grown increasingly fragile, state-coupled, and side-effect prone. Its current design makes it difficult to reason about, extend safely, or test in isolation.state-coupled, and side-effect prone. Its current design makes it difficult to reason about, extend safely, or test in isolation.

🚨 Problems Identified

1. Interleaving of Form State and Reducer State

• react-hook-form manages form data while a separate reducer manages pricing-related UI state.
• This causes duplication, unclear source of truth, and hard-to-debug race conditions between form and reducer logic.

2. Side-Effect Driven Updates

• Critical updates (like pricing type or validation rules) depend on complex useEffect chains.
• These useEffects are triggered implicitly by field changes, making flows difficult to predict and test.
• Internal updates to form fields can unintentionally retrigger downstream effects → feedback loops.

3. Overuse of reset() and Unconditional setValue()

• The component often calls reset() or setValue() without checking if the value actually changed.
• This results in unnecessary re-renders and invalidates user input in some cases.

4. No Centralized Validation Logic

• Pricing validation (min, max) is updated in multiple places (slab, category, payment mode, etc).
• This logic is duplicated and spread across multiple useEffects instead of being derived in a single place.

5. Poor Separation of Concerns

• Component is tightly coupled to business rules (agent types, slab structure, validation strategy). As a result, it’s hard to re-use or refactor in isolation.

6. Difficult to Extend or Reuse

• Adding new fields (e.g., agent location, commission cap) or new pricing types requires touching many places.
• Lack of modular structure (e.g., no field schema abstraction) means high risk of regressions.