Building a Transaction from User Input

Hello! Let's dive into our next lesson.

In our last session, we successfully built the user interface for our dApp, creating a form with controlled components to capture input for our Solana program. We now have the "what" – the data the user wants to send. Today, we'll focus on the "how" – taking that data, constructing a transaction, and submitting it to the blockchain. This is where your dApp truly comes to life, moving from a static front-end to an interactive application that can change on-chain state.

This lesson directly addresses the learning outcome: Construct and submit a program transaction based on user input from the UI. We'll see how the Anchor framework makes this process remarkably straightforward, connecting our React component's state directly to our on-chain Rust logic.

From UI State to Blockchain Instruction

Recall the update function from our last lesson's example. We had an <input> element bound to a state variable, let's call it input. The goal is to pass the value of input to our on-chain program.

With Anchor, this is primarily handled by the program.rpc object. Each function you define in your Rust #[program] block becomes a method on program.rpc that you can call from your client.

Let's look at the full-stack "message board" dApp from the guide we've been following. This will serve as our primary reference for this lesson.

The Anatomy of an Anchor RPC Call

After reviewing the code, let's break down the most important line in the client-side update function:

await program.rpc.update(input, {
  accounts: {
    baseAccount: baseAccount.publicKey
  }
});

This single call is doing a lot of work. Let's dissect it:

1. program.rpc.update(...): This is the Remote Procedure Call (RPC). update directly corresponds to the public function update in the Rust #[program] block. Anchor generates this client-side binding for you automatically.

2. input: This is the first argument. It's the input state variable from our React component. Notice how it maps directly to the data: String parameter in the Rust function signature: pub fn update(ctx: Context<Update>, data: String) -> ProgramResult. Anchor handles the serialization of this JavaScript string into the format the Rust program expects.

3. { accounts: { ... } }: This is the Context object. It corresponds to the ctx: Context<Update> parameter in the Rust function. The accounts property within this object is where you provide the public keys for all the accounts defined in your Update struct in Rust.

   • In Rust: pub base_account: Account<'info, BaseAccount>
   • In TypeScript: baseAccount: baseAccount.publicKey
     This mapping tells the Solana runtime which on-chain account it needs to load and pass into your program instruction.

Your experience with function calls and passing arguments in JavaScript is directly applicable here. The main difference is that in addition to the data arguments (input), you must also provide the accounts context so the blockchain knows which state to operate on.

The User's Role: Signing the Transaction

When the await program.rpc.update(...) line is executed, something magical happens. Anchor constructs the transaction, but it can't send it alone. A transaction that changes data or transfers assets requires a signature from the fee payer and any other required signers.

Since our Provider was configured with the user's connected wallet, the Anchor library will automatically hand this constructed transaction over to the wallet. The wallet (e.g., Phantom) will then display a pop-up asking the user to review and approve the transaction.

This video provides a great visual for this exact moment.

This wallet prompt is a cornerstone of Web3 security. Your dApp can only propose actions; the user always has the final say and must authorize any state change or expenditure of funds with their private key.

// In the #[program] block
pub fn create_profile(ctx: Context<CreateProfile>, username: String, age: u8) -> ProgramResult { ... }

// The Accounts struct
#[derive(Accounts)]
pub struct CreateProfile<'info> {
    #[account(init, payer = user, space = 96)]
    pub profile_account: Account<'info, Profile>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program <'info, System>,
}

await program.rpc.createProfile(formData.username, formData.age, {
  accounts: {
    profileAccount: profileAccount.publicKey,
    user: provider.wallet.publicKey,
    systemProgram: SystemProgram.programId,
  },
  signers: [profileAccount],
});

Handling Success and Failure

The await keyword means your code will pause until the transaction is processed. But what happens then? The call can either succeed or fail. As a developer, you need to handle both cases to provide a good user experience.

This is where a try...catch block becomes essential.

Look again at the createCounter function in the first "Hello World" example from the Nader Dabit guide.

In the try block:

1. The transaction is sent via program.rpc.
2. After it succeeds, the code proceeds to const account = await program.account.baseAccount.fetch(...). This re-fetches the account's data from the blockchain.
3. The UI state is then updated with the new data (setValue(account.count.toString())), giving the user instant feedback that their action was successful.

In the catch (err) block:

• console.log("Transaction error: ", err); is used to log the error. In a real application, you would use this block to display a user-friendly error message (e.g., "Transaction failed. Please try again.").

This try...catch pattern is fundamental for robust dApp development. A transaction can fail for many reasons: the user rejecting it in their wallet, insufficient funds for fees, or a logic error in your on-chain program. Gracefully handling these failures is critical.

Conclusion

Congratulations! You have now connected all the dots from user interface to on-chain execution. You can build a form, capture user input, and use that input to construct and submit a transaction that permanently alters the state of the Solana blockchain.

Key Takeaways:

• program.rpc is the Bridge: Anchor's program.rpc.instructionName() method is the primary tool for calling your on-chain program from the client.
• Arguments and Context: An RPC call takes the instruction's data arguments first, followed by a context object containing the accounts and any additional signers.
• Automatic Signing: The Provider object automatically triggers the user's wallet to prompt for a signature, ensuring user control and security.
• Update the UI on Success: After a successful transaction, you should re-fetch the on-chain data to reflect the new state in your dApp's UI.
• Handle Errors Gracefully: Always wrap transaction submissions in a try...catch block to manage potential failures and provide clear feedback to the user.

Preview of the Next Lesson:

When we await a transaction, what are we actually waiting for? The Solana network has different stages of transaction confirmation: processed, confirmed, and finalized. Understanding these "commitment levels" is crucial for building responsive and reliable applications. In our next lesson, we will dive into what these levels mean and how to use them to give your users precise and timely feedback on the status of their transactions.