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.
const myAccount = new anchor.web3.Account();
// Atomically create the new account and initialize it with the program.
await program.rpc.myInstruction(...args, {
accounts: {
myAccount: myAccount.publicKey,
},
signers: [myAccount],
instructions: [
await program.account.MyAccount.createInstruction(myAccount),
],
});
With the #[anchor(init)] attribute, this example can be transformed into
await program.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 IDL