Closed prxgr4mm3r closed 1 month ago
After investigation, I realized many problems with input field generating. Types that need to be supported:
i8
, i16
, i32
, i64
, i128
, u256
, usize
.Integer types It is the easiest part. We just need to add these types to the list of supported core types and declare ranges of valid values.
ByteArray
This type is used just to represent string
in smart-contracts, so we need to add this type to supported core types and work with input as with string
Custom Structs
For example we have Input
struct:
#[derive(Drop, Serde, starknet::Store)]
pub struct Input {
value1: u256,
value2: ByteArray
}
And the constructor interface will look like:
fn constructor(ref self: ContractState, initial_values: Input)
We found that the field initial_values
type is not a 'core' in this case. In Abi, this struct type will look like projName::contractName::Input
. So we need to search for this type in Abi and then identify it. If it is struct we need to parse all of its field types and add them in our form. So we will have u256
input field for value1
and ByteArray
for value2
.
Custom Enums
For example, we have Input
enum:
#[derive(Drop, Serde, starknet::Store)]
pub struct Input {
None,
Value: u256
}
And the same constructor as we have in the example for structs. In this case, I think we can do a drop-down menu of enum variants and an input field that depends on what enum variant we choose. For None
we will not have any input fields, and for Value
one u256
input field.
Nested Types Also, we can use Structs and Enums as types of fields of other Structs and Enums. It is the most complicated case. In this case, some recursive approach might be used. Investigation needed.
When the contract's abi consists of some 'not expected' types, no input fields are generated. For example, if you have a contract constructor ABI like this:
We will have the following output(I have used a storybook to demonstrate):
As you see field ![image](https://github.com/user-attachments/assets/37239097-db7b-415f-968a-529db8067fe8)
total_supply
is mentioned on the top, but there isn't an input field for it. If we will changeinitial_supply
type fromcore::integer::u256
tocore::integer::u128
it will work correctly:So I think the problem is in some kind of type verification.