You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filing a tracking issue, though I don't love the idea at the moment and am inclined to throw this idea away.
IDL change and client generation
An additional feature the #[account(init)] attribute enables is the ability for clients to know when they should create accounts in the same transaction as executing a program instruction.
Currently, when executing this type of instruction, clients must manually add the account creation instruction as follows.
// The Account to create.constmyAccount=newanchor.web3.Account();// Atomically create the new account and initialize it with the program.awaitprogram.rpc.myInstruction(...args,{accounts: {myAccount: myAccount.publicKey,},signers: [myAccount],instructions: [awaitprogram.account.MyAccount.createInstruction(myAccount),],});
With the #[anchor(init)] attribute, this example can be transformed into
awaitprogram.rpc.myInstruction(...args);
Since the client generator can read a new isInit field in the IDL
@armaniferrante should i take this up? I was building a transpiler for anchor to seahorse and this was a problem as it doesnt know which accounts are being initialized
Filing a tracking issue, though I don't love the idea at the moment and am inclined to throw this idea away.
IDL change and client generation
An additional feature the
#[account(init)]
attribute enables is the ability for clients to know when they should create accounts in the same transaction as executing a program instruction.Currently, when executing this type of instruction, clients must manually add the account creation instruction as follows.
With the
#[anchor(init)]
attribute, this example can be transformed intoSince the client generator can read a new
isInit
field in the IDLThe text was updated successfully, but these errors were encountered: