Implement some way of tying together enums and instruction parameter structs in the autogenerated code

[jarry-xiao]

The one thing that i wish shank could do a little better on the code generation side is to allow for instruction identifiers and instruction parameters to be split up into 2 separate components. Here are 2 examples from the typescript client for Phoenix:

I had to inject logic into this function to get it to work properly. This is what one of them looks like at generation:

Reference:
https://github.com/Ellipsis-Labs/phoenix-sdk/blob/master/typescript/phoenix-sdk/src/instructions/Swap.ts#L58
https://github.com/Ellipsis-Labs/phoenix-sdk/blob/master/typescript/phoenix-sdk/src/instructions/CancelMultipleOrdersById.ts#L68

This minimal amount of boilerplate isn't the end of the world, but it would be nice if there was some way to have this work done for me. If I could tag the struct that I wanted to include as a parameter:

 #[parameter(instruction=0, param_index=0, name = "cancel_order_params")]

I think it should in theory be possible to group everything together.

Maybe this is more suited for Solita. I think this is an awesome tool that really doesn't try to force me into a hole when programming. I like being able to write pure Rust code without having to jump through hoops imposed by a framework.

[febo]

@jarry-xiao Wondering if this is still an issue. If I understood correctly what you are describing, I think you can use an enum with data for your instructions – e.g.:

pub enum Instruction {
    Swap(OrderPacket),
    ...
}

The generated code will then expect an OrderPacket object as a parameter to create the Swap instruction.

[jarry-xiao]

I worked around this by injecting some logic into our IDL generation. Really appreciate this tool being so flexible

[jarry-xiao]

When we make our program open source, I'll link our solution here