Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (1)

8-20: Missing onSave callback to refresh parent data.

The component signature doesn't accept an onSave prop, so the parent's callback is dropped and the page data won't refresh after a successful save. This issue was already flagged in a previous review.

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

174-180: Modal integration issue already flagged.

The handleModalSave callback is defined here but AddReverseWithdrawModal doesn't accept an onSave prop, so this callback is never invoked. This was already flagged in the previous review of the modal component.

includes/DependencyManagement/Providers/AdminDashboardServiceProvider.php (2)

15-15: Consider alphabetical ordering of imports.

The import is correct, but for consistency and maintainability, consider placing it in alphabetical order with the other page imports (between ProFeatures and SetupGuide).

---

43-43: Remove redundant inline comment.

The inline comment is self-explanatory from the code itself and inconsistent with other entries in the array.

Apply this diff:

-        ReverseWithdrawal::class, // Added ReverseWithdrawal page service
+        ReverseWithdrawal::class,

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (2)

183-189: Remove unnecessary memoization wrapper.

The memoizedSetFilterArgs callback doesn't provide any real benefit since setFilterArgs from useState is already stable, and React's setState natively handles both function and value forms. This adds unnecessary complexity.

-    // Memoize setFilterArgs to prevent unnecessary re-renders of StoreFilter
-    const memoizedSetFilterArgs = useCallback((newArgs) => {
-        if (typeof newArgs === 'function') {
-            setFilterArgs(newArgs);
-        } else {
-            setFilterArgs(newArgs);
-        }
-    }, []);
-
     // Move DateFilter outside or memoize it
     const DateFilter = useCallback(() => {

Then update line 272:

-        <StoreFilter key="store_filter" filterArgs={filterArgs} setFilterArgs={memoizedSetFilterArgs} />,
+        <StoreFilter key="store_filter" filterArgs={filterArgs} setFilterArgs={setFilterArgs} />,

---

227-227: Add space after if keyword.

Minor style inconsistency.

-            if(tempAfter && tempBefore) {
+            if (tempAfter && tempBefore) {

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (2)

131-168: Update useCallback dependencies to include date parameters.

The fetchData function uses dateAfter and dateBefore from its closure (default parameter values on line 131) but doesn't include them in the dependency array on line 168. This causes stale closure issues where the callback won't update when the date values change.

Apply this diff:

-    }, [view.page, view.perPage, filterArgs]);
+    }, [view.page, view.perPage, filterArgs, dateAfter, dateBefore]);

---

192-268: Extract DateFilter as a separate component to avoid reconciliation issues.

Defining a component inside another component (even with useCallback) is an anti-pattern. When the parent re-renders and dependencies change, React creates a new component function, causing unmounts/remounts that lose internal state and break user interactions.

Move DateFilter outside ReverseWithdrawalPage as a standalone memoized component:

+const DateFilter = memo(({ dateAfter, dateAfterText, dateBefore, dateBeforeText, focusedInput, setDateAfter, setDateAfterText, setDateBefore, setDateBeforeText, setFocusedInput, fetchData }) => {
+    const [tempAfter, setTempAfter] = useState(dateAfter);
+    const [tempAfterText, setTempAfterText] = useState(dateAfterText);
+    const [tempBefore, setTempBefore] = useState(dateBefore);
+    const [tempBeforeText, setTempBeforeText] = useState(dateBeforeText);
+    const [tempFocused, setTempFocused] = useState(focusedInput);
+    
+    // ... rest of the component logic
+});
+
+DateFilter.displayName = 'DateFilter';
+
 const ReverseWithdrawalPage = () => {
     // ...
-    const DateFilter = useCallback(() => {
-        // ...
-    }, [dateAfter, dateAfterText, dateBefore, dateBeforeText, focusedInput, fetchData]);

Then pass props explicitly:

-        <DateFilter key="date_filter" />,
+        <DateFilter 
+            key="date_filter" 
+            dateAfter={dateAfter}
+            dateAfterText={dateAfterText}
+            dateBefore={dateBefore}
+            dateBeforeText={dateBeforeText}
+            focusedInput={focusedInput}
+            setDateAfter={setDateAfter}
+            setDateAfterText={setDateAfterText}
+            setDateBefore={setDateBefore}
+            setDateBeforeText={setDateBeforeText}
+            setFocusedInput={setFocusedInput}
+            fetchData={fetchData}
+        />,

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (5)

8-8: Add missing onSave prop to enable page refresh.

The component only destructures open and onClose, dropping the onSave callback passed from the parent page. Without this, successful submissions don't trigger a data refresh, leaving the dashboard stale.

Apply this diff:

-const AddReverseWithdrawModal = ({ open, onClose }) => {
+const AddReverseWithdrawModal = ({ open, onClose, onSave }) => {

Then update the success handler (see comment on lines 69-86).

---

9-11: Fix typo: "transectionType" → "transactionType".

The state variable is consistently misspelled as "transectionType" instead of "transactionType" throughout the file.

Apply a global find-and-replace:

-    const [transectionType, setTransectionType] = useState<
+    const [transactionType, setTransactionType] = useState<
         'manual_product' | 'manual_order' | 'other'
     >('manual_product');

(Apply to all 12 occurrences in the file)

---

69-86: Improve error handling and remove debug code.

Multiple issues in this block:

1. Missing onSave call: After successful POST, the callback isn't invoked, so the parent page never refreshes.
2. Console.log in production: Debug logging should be removed (line 79).
3. Silent error handling: Errors are re-thrown without user feedback, leaving the modal open with no indication of what failed.

Apply these fixes:

         try {
             const response = await apiFetch({
                 path: 'dokan/v1/reverse-withdrawal/transactions',
                 method: 'POST',
                 data: payload,
             });
 
             resetForm();
-            onClose();
-            console.log('Reverse withdrawal created successfully:', response);
+            onSave?.(response);
+            onClose();
         } catch (error) {
-            console.error('Error saving reverse withdrawal:', error);
-            throw error;
+            setErrors({ submit: __('Failed to create reverse withdrawal. Please try again.', 'dokan-lite') });
         } finally {
             setLoading(false);
         }

---

161-188: Change id to seller_id in ProductAsyncSelect extraQuery.

The ProductAsyncSelect uses id: vendorsData.value to filter products by vendor (line 173), but this is inconsistent with the OrderAsyncSelect on line 204 which correctly uses seller_id: vendorsData.value. The product API expects seller_id for vendor filtering.

Apply this diff:

 extraQuery={{
-    ...(vendorsData?.value ? { id: vendorsData.value } : {}),
+    ...(vendorsData?.value ? { seller_id: vendorsData.value } : {}),
     post_status: 'publish',
 }}

---

305-320: Fix dynamic height class for Tailwind JIT compatibility.

The template literal in the className on line 311 (h-[${transectionType === 'other' ? '718px' : '818px'}]) won't work with Tailwind JIT mode because the complete class names must be statically detectable at build time.

Apply this diff:

-            className={`w-full sm:w-[620px] max-w-[95%] h-[${transectionType === 'other' ? '718px' : '818px'}] max-h-[96vh] flex flex-col`}
+            className={`w-full sm:w-[620px] max-w-[95%] ${transectionType === 'other' ? 'h-[718px]' : 'h-[818px]'} max-h-[96vh] flex flex-col`}

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

182-189: Simplify memoizedSetFilterArgs or remove it.

The memoizedSetFilterArgs wrapper is unnecessary because setFilterArgs (from useState) is already stable. Additionally, both branches of the conditional execute identical code, making the condition redundant.

You can either:

1. Remove the wrapper and pass setFilterArgs directly to StoreFilter
2. Or simplify to just pass through the argument:

 const memoizedSetFilterArgs = useCallback((newArgs) => {
-    if (typeof newArgs === 'function') {
-        setFilterArgs(newArgs);
-    } else {
-        setFilterArgs(newArgs);
-    }
+    setFilterArgs(newArgs);
 }, []);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

160-161: Consider logging fetch errors for debugging.

The empty catch block silently suppresses errors. While setting empty data is a reasonable fallback, logging would help diagnose API issues.

-        } catch {
+        } catch (error) {
+            console.error('Failed to fetch reverse withdrawal data:', error);
             setData( [] );
         } finally {

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (4)

15-15: Hook modal success so the page refreshes.

The component signature still doesn't accept an onSave callback, so after a successful POST the parent page cannot refresh its data. This was flagged in previous reviews.

---

16-18: Fix typo: "transectionType" → "transactionType".

The state variable remains misspelled throughout the file. This was flagged in previous reviews.

---

93-95: Improve error handling for better UX.

The catch block re-throws the error without providing user feedback, leaving the modal open with no indication of what went wrong. This was flagged in previous reviews.

---

232-237: Change id to seller_id in ProductAsyncSelect extraQuery.

Line 234 uses id: vendorsData.value while the OrderAsyncSelect correctly uses seller_id: vendorsData.value on line 271. This inconsistency was flagged in previous reviews.

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (1)

47-49: Consider validating amount is a positive number.

The validation only checks if withdrawalAmount is truthy, but doesn't verify it's a valid positive number. This could allow invalid values like negative numbers or non-numeric strings to be submitted.

Apply this diff to add number validation:

     if ( ! withdrawalAmount ) {
         newErrors.withdrawalAmount = true;
+    } else if ( isNaN( Number( withdrawalAmount ) ) || Number( withdrawalAmount ) <= 0 ) {
+        newErrors.withdrawalAmount = true;
     }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: mrabbani
Repo: getdokan/dokan PR: 2891
File: src/admin/dashboard/pages/vendors-single/InformationTabs/WithdrawTab.tsx:58-59
Timestamp: 2025-09-19T06:19:41.376Z
Learning: The Dokan codebase uses 'dokan-lite' as the text domain for WordPress internationalization (__() function calls).

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (2)

26-28: Rename transectionType → transactionType for clarity

The state and related handlers are consistently misspelled as transectionType. This hurts readability and can be confusing long‑term.

A simple find‑and‑replace to transactionType / setTransactionType would clarify intent.

Also applies to: 141-147, 217-238

---

41-68: Handle API errors in the modal instead of just logging and re‑throwing

On failure, the catch block only logs to the console and re‑throws. The modal stays open but the user receives no feedback and the thrown error may bubble in unexpected ways.

Recommend:

• Remove the console.log (no console.* in production code).
• Capture the error into component state (e.g., errors.submit) or trigger a global toast/notice so the user sees a clear message.
• Do not re‑throw from here; rely on the UI error path instead.

Also applies to: 86-115

src/admin/dashboard/pages/reverse-withdrawal/AddReverseWithdrawModal.tsx (3)

153-161: Debounced amount state can be stale at submit time

DokanPriceInput’s onChange feeds a 500 ms‑debounced debouncedWithdrawAmount, and both the displayed value and the payload (withdrawalAmountRaw) come from that debounced state. If an admin edits the amount and immediately clicks “Add New”, you may post the previous amount.

Consider keeping a non‑debounced state for the actual submitted value (and optionally debounce only any heavy side‑effects), or drop the debounce if it isn’t needed.

Also applies to: 382-417

---

382-417: Avoid hard‑coded $ currency symbol

The amount input overlays a literal $ prefix while also using DokanPriceInput, which is already currency‑aware. This can:

• Show the wrong symbol in non‑USD stores.
• Potentially duplicate the symbol if DokanPriceInput renders one.

Prefer pulling the symbol from the store settings (or letting DokanPriceInput handle it) instead of hard‑coding $.

If DokanPriceInput already renders the store currency symbol, remove the manual $ span to avoid duplication.

---

39-40: Strongly type errors for better safety

errors is initialized as a bare {} and later accessed with properties like errors.vendorId, errors.trId, etc. Without an explicit type, this bypasses TypeScript’s safety and can hide typos in error keys.

Defining an interface, e.g.:

type FormErrors = {
    vendorId?: boolean;
    trId?: boolean;
    withdrawalAmount?: boolean;
    withdrawalNote?: boolean;
    submit?: string;
};

const [ errors, setErrors ] = useState<FormErrors>( {} );

would make access and updates much safer.

Also applies to: 118-128

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (1)

171-180: Consider server‑side pagination instead of per_page: -1

The transactions fetch uses per_page: -1 and then sets paginationInfo={{ totalItems, totalPages: 1 }}. For vendors with many transactions, this can become a heavy request and slow UI.

If the API supports it, consider:

• Using per_page: view.perPage and a real totalPages from headers or data length.
• Wiring view.page into queryArgs and paginationInfo.

This would keep the UI responsive on large datasets.

Also applies to: 487-488

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (2)

201-332: Optional: actually memoize filterFields to avoid recreating inline components

filterFields is re‑declared on every render, and each field contains inline JSX with closures over component state. The comment says “Memoize filter fields,” but no useMemo is used.

This is not a correctness bug, but you could wrap it in useMemo with appropriate deps (date/vender/filter state) to reduce unnecessary recalculations and avoid potential re‑mounts if the DataViews implementation compares fields by reference.

---

430-438: Confirm that closing the modal only on success matches desired UX

onCreated both closes the modal and triggers fetchData, while onClose simply hides it. If the POST fails inside the modal, onCreated is never called and the modal remains open (which is good), but combined with the current modal error handling (no user‑visible error from the child), admins may not realize something went wrong.

Once AddReverseWithdrawModal surfaces a clear error, this pattern is fine; otherwise, consider also showing a toast here when onCreated is not invoked due to failure.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: mrabbani
Repo: getdokan/dokan PR: 2891
File: src/admin/dashboard/pages/vendors-single/InformationTabs/WithdrawTab.tsx:58-59
Timestamp: 2025-09-19T06:19:41.376Z
Learning: The Dokan codebase uses 'dokan-lite' as the text domain for WordPress internationalization (__() function calls).

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (1)

180-225: Include full view (or at least view.sort) in fetchTransactions dependencies so sorting works correctly

fetchTransactions builds orderby/order from view.sort:

const queryArgs: any = {
    orderby: ( view as any )?.sort?.field || 'added',
    order: ( view as any )?.sort?.direction || 'desc',
    vendor_id: vendorId,
    per_page: -1,
    ...filterArgs,
};

but the hook dependencies only include view.page, view.perPage, and filterArgs. If the user changes sort without changing page/perPage, the closure keeps using the old sort and the effect won’t re‑run, so the table doesn’t actually resort on the server.

Updating the deps to include the sort state fixes this:

-    }, [ vendorId, view.page, view.perPage, filterArgs ] );
+    }, [ vendorId, view, filterArgs ] );

(or depend specifically on view.sort if you want to be more granular).

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

117-167: Update fetchData dependencies so sort changes (and other view changes) trigger a refetch

fetchData constructs query args using view.sort.field/view.sort.direction:

const queryArgs = {
    per_page: view.perPage,
    page: view.page,
    orderby: ( view as any )?.sort?.field || 'added',
    order: ( view as any )?.sort?.direction || 'desc',
    ...filterArgs,
};

but the useCallback only depends on view.page, view.perPage, and filterArgs. If the user adjusts sorting without changing page/perPage, the request will still use the previous sort and the effect watching fetchData won’t fire.

Safer to depend on the full view object (or at least view.sort) so any sort or layout change is reflected:

-    }, [ view.page, view.perPage, filterArgs ] );
+    }, [ view, filterArgs ] );

This keeps the backend data consistent with the current table view.

includes/REST/ReverseWithdrawalController.php (1)

230-246: Verify new trn_date defaulting semantics and avoid surprising changes for partial ranges

Controller now always normalizes trn_date:

$default_transaction_date = Helper::get_default_transaction_date();
$request_params           = $request->get_params();
// ...
$request_params['trn_date'] = [
    'from' => $request_params['trn_date']['from'] ?? $default_transaction_date['from'],
    'to'   => $request_params['trn_date']['to'] ?? $default_transaction_date['to'],
];

and the route schema marks trn_date as optional with nested defaults.

This is good for the new UI (it can omit trn_date entirely and still get a sane last‑X‑days window), but it also subtly changes API behavior for callers that previously sent only a from or only a to date – those now get the default on the missing side instead of an open‑ended range.

If open‑ended ranges should remain supported for API consumers, consider only applying the defaults when trn_date is absent or both from and to are empty, e.g.:

-        // Set default trn_date if not set.
-        $request_params['trn_date'] = [
-            'from' => $request_params['trn_date']['from'] ?? $default_transaction_date['from'],
-            'to'   => $request_params['trn_date']['to'] ?? $default_transaction_date['to'],
-        ];
+        // Set default trn_date only when no bounds are provided.
+        if (
+            empty( $request_params['trn_date']['from'] )
+            && empty( $request_params['trn_date']['to'] )
+        ) {
+            $request_params['trn_date'] = $default_transaction_date;
+        }

If the intent is to always clamp to a bounded range for this endpoint, then this change looks fine but should be called out explicitly in API/feature docs so consumers know open‑ended ranges are no longer possible.

Also applies to: 633-671

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

118-168: Ensure sort changes trigger data refetch in fetchData

fetchData builds orderby/order from view.sort, but the hook’s dependency array only includes view.page, view.perPage, and filterArgs. Changing sort alone won’t recreate fetchData or re-run the effect, so the API keeps using stale sort values.

Consider depending on the full view (or at least view.sort) so sort changes refetch data:

-    }, [ view.page, view.perPage, filterArgs ] );
+    }, [ view, filterArgs ] );

This keeps behaviour for page/perPage while making sort reactive.

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (1)

181-226: Include view sort in fetchTransactions dependencies to avoid stale sorting

fetchTransactions reads view.sort.field / view.sort.direction but the dependency array only includes vendorId, view.page, view.perPage, and filterArgs. Sort changes won’t recreate the callback or trigger the effect, so the API keeps using the previous sort.

Update dependencies so sort changes refetch:

-    }, [ vendorId, view.page, view.perPage, filterArgs ] );
+    }, [ vendorId, view, filterArgs ] );

This also removes unused deps (view.page/view.perPage aren’t used in the query).

src/admin/dashboard/pages/reverse-withdrawal/index.tsx (1)

210-323: Align filterFields implementation with the “memoize” intent

The comment says “Memoize filter fields to prevent recreation”, but filterFields is a plain array literal, so it’s rebuilt on every render (including the inline VendorAsyncSelect and DateRangePicker elements).

Either remove/adjust the comment, or actually memoize:

-import DateRangePicker from '@src/components/DateRangePicker';
+import DateRangePicker from '@src/components/DateRangePicker';
@@
-    // Memoize filter fields to prevent recreation
-    const filterFields = [
+    // Memoize filter fields to avoid unnecessary re-renders
+    const filterFields = useMemo(
+        () => [
         {
             id: 'vendor',
@@
         {
             id: 'date-range',
@@
-        },
-    ];
+        },
+    ], [
+        vendorFilter,
+        filterArgs,
+        dateAfter,
+        dateAfterText,
+        dateBefore,
+        dateBeforeText,
+        focusedInput,
+    ] );

(You’d also need to import useMemo from @wordpress/element.)

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (1)

302-400: Consider extracting a shared date‑range filter abstraction

The DateRangePicker + SimpleInput + trn_date wiring here is almost identical to the date‑range filter in reverse-withdrawal/index.tsx. Duplicating this logic in two pages makes future fixes (formatting, default ranges, edge cases) harder.

Consider extracting a small shared helper (component or hook) that encapsulates:

• Local date state mapping (after/before, text, focusedInput)
• Building/clearing trn_date inside filterArgs
• Display formatting via displayDateRange

Then use it in both pages to keep behaviour consistent.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (1)

181-226: Include view.sort in dependencies to ensure sorting works correctly.

This is a continuation of the previous review comment. The fetchTransactions callback reads view.sort.field and view.sort.direction (lines 190-191) but only depends on [vendorId, view.page, view.perPage, filterArgs]. When the user changes sort order without changing page or perPage, the callback won't update and will continue using stale sort values.

-    }, [ vendorId, view.page, view.perPage, filterArgs ] );
+    }, [ vendorId, view.page, view.perPage, view.sort, filterArgs ] );

Alternatively, depend on the entire view object if you prefer:

-    }, [ vendorId, view.page, view.perPage, filterArgs ] );
+    }, [ vendorId, view, filterArgs ] );

Additional concern: Lines 189-191 use type assertions (as any) that bypass TypeScript's type checking. Consider defining a proper type for the view state or using the correct type from the DataViews library.

src/admin/dashboard/pages/reverse-withdrawal/ReverseWithdrawalTransaction.tsx (2)

86-137: Extract common monetary value rendering logic to reduce duplication.

The render functions for debit, credit, and balance fields share nearly identical logic (empty check, parseFloat, NaN check, negative value handling). This duplication increases maintenance burden and risk of inconsistency.

Consider extracting a shared helper:

+const renderMonetaryValue = ( value ) => {
+    if ( value === '' ) {
+        return <span>--</span>;
+    }
+    const amt = parseFloat( value );
+    if ( isNaN( amt ) ) {
+        return <span>--</span>;
+    }
+    return amt < 0 ? (
+        <div className="flex">( { price( Math.abs( amt ) ) } )</div>
+    ) : (
+        <div className="flex">{ price( amt ) }</div>
+    );
+};
+
 const fields = [
     // ... other fields
     {
         id: 'debit',
         label: __( 'Debit', 'dokan-lite' ),
-        render: ( { item } ) => {
-            if ( item.debit === '' ) {
-                return <span>--</span>;
-            }
-            const amt = parseFloat( item.debit );
-            if ( isNaN( amt ) ) {
-                return <span>--</span>;
-            }
-            return amt < 0 ? (
-                <div className="flex">( { price( Math.abs( amt ) ) } )</div>
-            ) : (
-                <div className="flex">{ price( amt ) }</div>
-            );
-        },
+        render: ( { item } ) => renderMonetaryValue( item.debit ),
     },
     {
         id: 'credit',
         label: __( 'Credit', 'dokan-lite' ),
-        render: ( { item } ) => {
-            if ( item.credit === '' ) {
-                return <span>--</span>;
-            }
-            const amt = parseFloat( item.credit );
-            if ( isNaN( amt ) ) {
-                return <span>--</span>;
-            }
-            return amt < 0 ? (
-                <div className="flex">( { price( Math.abs( amt ) ) } )</div>
-            ) : (
-                <div className="flex">{ price( amt ) }</div>
-            );
-        },
+        render: ( { item } ) => renderMonetaryValue( item.credit ),
     },
     {
         id: 'balance',
         label: __( 'Balance', 'dokan-lite' ),
-        render: ( { item } ) => {
-            if ( item.balance === '' ) {
-                return <span>--</span>;
-            }
-            const amt = parseFloat( item.balance );
-            if ( isNaN( amt ) ) {
-                return <span>--</span>;
-            }
-            return amt < 0 ? (
-                <div className="flex">( { price( Math.abs( amt ) ) } )</div>
-            ) : (
-                <div className="flex">{ price( amt ) }</div>
-            );
-        },
+        render: ( { item } ) => renderMonetaryValue( item.balance ),
     },
 ];

---

141-148: Initialize sort property in view state for consistency and type safety.

The fetchTransactions callback (lines 190-191) accesses view.sort.field and view.sort.direction, but the initial view state doesn't include a sort property. While the code safely falls back using optional chaining and defaults, explicitly initializing sort improves clarity and type safety.

 const [ view, setView ] = useState( {
     perPage: 100,
     page: 1,
     search: '',
     type: 'table',
     layout: { density: 'comfortable' },
     fields: fields.map( ( f ) => f.id ),
+    sort: {
+        field: 'trn_date',
+        direction: 'desc',
+    },
 } );

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro