Refactor withdraw requests to use DataViews tabs migration

[akzmoudud]

All Submissions:

• My code follow the WordPress' coding standards
• My code satisfies feature requirements
• My code is tested
• My code passes the PHPCS tests
• My code has proper inline documentation
• I've included related pull request(s) (optional)
• I've included developer documentation (optional)
• I've added proper labels to this pull request

Changes proposed in this Pull Request:

Related Pull Request(s)

• Full PR Link

Closes

• Closes https://github.com/getdokan/plugin-internal-tasks/issues/1590

How to test the changes in this Pull Request:

• Steps or issue link

Changelog entry

Refactored withdraw requests UI to use DataViews tabs

Before Changes

Describe the issue before changes with screenshots(s).

After Changes

Describe the issue after changes with screenshot(s).

Feature Video (optional)

Link of detailed video if this PR is for a feature.

PR Self Review Checklist:

• Code is not following code style guidelines
• Bad naming: make sure you would understand your code if you read it a few months from now.
• KISS: Keep it simple, Sweetie (not stupid!).
• DRY: Don't Repeat Yourself.
• Code that is not readable: too many nested 'if's are a bad sign.
• Performance issues
• Complicated constructions that need refactoring or comments: code should almost always be self-explanatory.
• Grammar errors.

FOR PR REVIEWER ONLY:

As a reviewer, your feedback should be focused on the idea, not the person. Seek to understand, be respectful, and focus on constructive dialog.

As a contributor, your responsibility is to learn from suggestions and iterate your pull request should it be needed based on feedback. Seek to collaborate and produce the best possible contribution to the greater whole.

• Correct — Does the change do what it’s supposed to? ie: code 100% fulfilling the requirements?
• Secure — Would a nefarious party find some way to exploit this change? ie: everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities?
• Readable — Will your future self be able to understand this change months down the road?
• Elegant — Does the change fit aesthetically within the overall style and architecture?

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 83782b00-2392-4e9b-984c-c34534cf9e86

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch refactor/withdraw-dataviews-migration

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[MdAsifHossainNadim]

Code Review — Needs Author Reply

CRITICAL

1. getItemId returns number, DataViews expects string

The getItemId callback returns item.id which is typed as number in the WithdrawRequest interface, but DataViews expects string. This will cause a type error or silent runtime issues with row selection/actions.

// Current
getItemId={ ( item: WithdrawRequest ) => item.id }

// Fix
getItemId={ ( item: WithdrawRequest ) => String( item.id ) }

---

ERROR

2. Massive DRY violation — ~100 lines of duplicated field definitions

pendingFields, approvedFields, and cancelledFields each repeat the same 5 field objects (amount, method_title, created, charge, receivable) verbatim. The only differences:

• pending adds a status column
• cancelled adds a note column

The existing RequestList.tsx already solves this cleanly with spread + conditional arrays:

const baseFields = [
    { id: 'amount', label: __('Amount', 'dokan-lite'), enableSorting: false,
      render: ({ item }: { item: WithdrawRequest }) => <PriceHtml price={item?.amount} /> },
    { id: 'method_title', ... },
    { id: 'created', ... },
    { id: 'charge', ... },
    { id: 'receivable', ... },
];

const statusField = { id: 'status', label: __('Status', 'dokan-lite'), ... };
const noteField = { id: 'note', label: __('Note', 'dokan-lite'), ... };

const getFieldsForStatus = (status: WithdrawStatus) => [
    ...baseFields,
    ...(status === 'pending' ? [statusField] : []),
    ...(status === 'cancelled' ? [noteField] : []),
];

This eliminates ~100 lines of duplication.

3. withdrawRequestsCompat stub couples to a dead interface

The compat shim creates a fake UseWithdrawRequestsReturn with 6 dummy/no-op properties just to satisfy RequestWithdrawBtn's type. Looking at RequestWithdrawBtn.tsx, it only actually uses withdrawRequests.data (to check pending requests) and withdrawRequests.refresh() (to reload after creating a withdraw). Consider refactoring RequestWithdrawBtn to accept a simpler interface, or at minimum add a TODO comment.

4. RequestList.tsx and useWithdrawRequests.ts not deleted but no longer used here

This PR inlines all logic from RequestList.tsx and useWithdrawRequests.ts but neither file is removed. RequestList is still imported by PaymentDetails.tsx, so it can't be removed without updating that too. Please document whether this is a known follow-up or scope this PR to also update PaymentDetails.tsx.

5. onViewChange has implicit any type

// Current — newView is implicitly `any`
const onViewChange = useCallback( ( newView ) => {
    setView( newView );
}, [] );

// Fix
const onViewChange = useCallback( ( newView: typeof view ) => {
    setView( newView );
}, [] );

---

WARNING

6. Field arrays recreated every render

pendingFields, approvedFields, cancelledFields, and allStatusLabels are defined inside the component body, creating new references every render. Move static definitions outside the component, or wrap computed fields in useMemo.

7. cancelRequestId unnecessary string/number conversion

Stored as string via String(item.id), consumed as Number(cancelRequestId). Simplify to number | null:

const [ cancelRequestId, setCancelRequestId ] = useState<number | null>( null );

8. Loading skeleton regression

The old RequestList.tsx renders animated pulse skeleton placeholders during loading. The new field renders don't. If the DataViews component from @wedevs/plugin-ui provides its own loading skeleton via isLoading, this is fine. If not, this is a UX regression — please verify.

---

SUGGESTION

9. Consider extracting data-fetching into a custom hook

The component now manages 7 state variables plus 3 useCallback fetch functions. Consider extracting the fetch logic into a new hook (e.g., useWithdrawDataView) to keep the component focused on rendering.

---

PR Template

• ❌ Screenshots — missing (required for UI refactor)
• ❌ Test instructions — placeholder not filled
• ❌ Labels — needs [Withdraw], [Vendor Dashboard], Type: Enhancement

[Shamim-97]

amount is double remove it

[akzmoudud]

amount is double remove it

Fixed