feat: new feedback components for transaction workflows

[vvm1004]

This pull request introduces a comprehensive set of reusable UI components to support transaction workflows in Murphy SDK. These components enhance the developer and end-user experience by providing consistent feedback mechanisms across multi-step dApp interactions such as minting, staking, and token transfers.

Below are the key additions grouped by functionality:

---

🔄 Step Flow and Dialog Components

• TxnProgressSteps — A visual step tracker (horizontal or vertical) to guide users through multi-step transaction flows (e.g., Connect → Submit → Confirm).
  File: components/ui/murphy/Txn-Feedback/txn-progress-steps.tsx

• StepFlowDialog — A modal wrapper for composing multi-step workflows, useful for guided flows like NFT minting or fusion.
  File: components/ui/murphy/Txn-Feedback/step-flow-dialog.tsx

• SuccessDialog — A confirmation modal shown after successful transactions, with optional explorer links and action buttons.
  File: components/ui/murphy/Txn-Feedback/success-dialog.tsx

---

⚠ Error Handling and Retry Logic

• TxErrorFallback — A fallback UI shown when a transaction fails, including retry capability and optional log display.
  File: components/ui/murphy/Txn-Feedback/txn-error-fallback.tsx

• TxRetryButton — A button component that wraps any action with built-in retry handling and transaction state awareness.
  File: components/ui/murphy/Txn-Feedback/txn-retry-button.tsx

---

📣 Feedback and Transaction Status

• TxFeedbackToast — Toast notifications that display transaction status updates such as preparing, confirming, success, and error.
  File: components/ui/murphy/Txn-Feedback/txn-feedback-toast.tsx

• TxnPendingIndicator — A global UI element that indicates when one or more transactions are still confirming, with optional positioning.
  File: components/ui/murphy/Txn-Feedback/txn-pending-indicator.tsx

• InlineTxStatus — Inline chips/icons to represent the state of individual transactions (pending, success, failure) in compact views.
  File: components/ui/murphy/Txn-Feedback/inline-txn-status.tsx

---

🔗 Blockchain Explorer Integration

• TxnExplorerLink — Renders a Solana Explorer link based on transaction signature and cluster, with support for various sizes and styles.
  File: components/ui/murphy/Txn-Feedback/txn-explorer-link.tsx

---

All components are:

• Lightweight and modular, built for reuse
• Fully compatible with Murphy SDK hooks like useWallet and useTransactionQueue
• Styled using Tailwind CSS and shadcn/ui to ensure visual consistency
• Designed with accessibility and mobile-friendliness in mind
• Accompanied by usage previews and examples

These additions significantly reduce boilerplate, prevent duplicated UI logic, and improve the clarity and trust of Solana transaction experiences in Murphy-powered applications.

[0xLou1s]

thanks @vvm1004 , will check & feedback ASAP

[0xLou1s]

hey @vvm1004 ! really appreciate the effort and the contribution here – clearly a lot of work went into this 🙌

that said, I’d like to give a few pieces of feedback to help align better with how we’re maintaining the codebase and reviewing contributions:

1. structure & tooling

• the repo uses pnpm, but this PR includes a yarn.lock file — could you remove that to avoid lockfile conflicts?
• also, the PR changes 54 files and adds over 16,000 lines of code, which makes it really hard to review carefully. we’d strongly prefer smaller, more focused PRs (ideally 1 component per PR) to allow for proper testing and discussion.

2. component design & previews

• for previewing new components, please follow the approach of previous examples and avoid importing components directly into MDX files.
• for instance, the TxnPendingIndicator could be better showcased if used inside an existing flow, like SendTokenForm, to illustrate real context and pending state UX. try building examples that integrate with actual component logic where possible.

3. priorities & scope

• we're currently prioritizing contributions to core logic like onchainkit, rather than expanding UI surface.
• since we’re using shadcn/ui, building UI and mock interactions is fairly straightforward — the real value comes from deep integration with the SDK and onchain workflows.

4. review strategy

• we'd really appreciate it if you could break this down and submit one PR per component or logical group.
• right now, reviewing everything in one go risks missing edge cases or best practices.

thanks again for taking the time to build all of this! excited to iterate and land these components — just want to make sure it happens in a way that scales with the rest of the codebase

[vvm1004]

Oke @0xLou1s, i will split each component into PR and send back to you, hope you will review

[vvm1004]

Hey @0xLou1s , here are some of my thoughts after doing and thinking back.

As for the preview component, there are some components that I have to write the preview component file outside of MDX; otherwise, it cannot be displayed or used properly because these are all reused components. For example, clicking on something is necessary to display both SuccessDialog and TxErrorFallback; however, the useState() hook required to open these components cannot be used in an MDX file.

As for deep integration with SDK and onchain workflows, I feel that my components can meet the requirements. For example, with Jupiter Recurring DCA’s Recurring Setup Form, when successful, you can use SuccessDialog or TxFeedbackToast; similarly, if it fails, you can use TxnErrorFallback, TxFeedbackToast, or integrate Step Flow Dialog into Swap Token Form.

However, I feel that I cannot write all my component code inside existing components because there are some things that I cannot test: Murphy configured them on Mainnet, I did not fully understand the business logic, or I simply did not feel confident editing existing code—although I have successfully integrated Step Flow Dialog into Swap Token Form. Therefore, I think I will use simple examples or describe how to use the components in the preview file and then use them in the MDX file. If I reuse old components and integrate a new one into the new MDX file, it feels repetitive, and I think users can also use the new component as they want.

And finally, these are just UI/UX components and don’t have much logic. If possible, I hope to contribute to more logic-oriented components in the following issues.

What do you think about this? Does it make sense to you?

[0xLou1s]

hey @vvm1004 , your reasoning makes sense 👍 thanks for clarifying. I'll go through your new PRs ASAP and leave feedback there. appreciate the contributions