Feat/Object From Struct String

[21Chani]

This PR will

Add a better handling for primitives conversion with object mapping

Before:

type ConvertPrimitiveArgType<TMoveType extends MovePrimitive> =
  TMoveType extends 'bool'
    ? boolean
    : TMoveType extends 'u8'
      ? number
      : TMoveType extends 'u16'
        ? number
        : TMoveType extends 'u32'
          ? number
          : TMoveType extends 'u64'
            ? AnyNumber
            : TMoveType extends 'u128'
              ? AnyNumber
              : TMoveType extends 'u256'
                ? AnyNumber
                : TMoveType extends 'address'
                  ? `0x${string}`
                  : TMoveType extends '0x1::string::String'
                    ? string
                    : never;

... ? ConvertPrimitiveArgType<TMoveType>

Now

import {  MovePrimitivesMap } from '../moveTypes.js';
... ? ConvertPrimitiveArgType[TMoveType]

This will ensure reusability and simplicity to the code, before 3 files for convertor was creating the same huge type 3 times for validating simple types

With this approach we can now just define a Map object with the respective type to a string or value:

export type MovePrimitivesMap = {
  '0x1::string::String': string;
  address: `0x${string}`;

  // Numeric types
  u8: number;
  u16: number;
  u32: number;
  u64: AnyNumber;
  u128: AnyNumber;
  u256: AnyNumber;

  bool: boolean;
};

This way we can avoid the the huge ternary verifications.

Add a convertor for struct objects

Using the fungible asset as example because I had to struggle a bit to support it with raw aptos package, aiming to provide full support for this in future with surf package.

[SamuelQZQ]

Thanks, @21Chani! I really appreciate your awesome PR. Would you mind adding a test file for return types, you could find some reference in src/core/__tests__/createViewPayload.test.ts? If you have a better proposal for testing type inference, that is also welcome!

[21Chani]

Thanks, @21Chani! I really appreciate your awesome PR. Would you mind adding a test file for return types, you could find some reference in src/core/__tests__/createViewPayload.test.ts? If you have a better proposal for testing type inference, that is also welcome!

Absolutely sir, will do it soon as I get back from gym

[21Chani]

Thanks, @21Chani! I really appreciate your awesome PR. Would you mind adding a test file for return types, you could find some reference in src/core/__tests__/createViewPayload.test.ts? If you have a better proposal for testing type inference, that is also welcome!

Sorry for the late, wasn't that simple, just added a new one to make sure type is safe now. Also with that realized that args also needed the same extractor as return, just added.

About the proposal for testing type, I had to do in this new way:

I think the effect is the same and for sure easier to code, when the type is a struct, the parsing gets really huge because is converted to bytes, guessing that to match snapshot perfectly might not be easy to maintain, although I don't know if this way I did is the best method for doing it, it is basically just the first one I found that works ok

Let me know what you think

[SamuelQZQ]

@21Chani My wrong, I should send this file for you as reference src/core/__tests__/view.test.ts. It checks ensure the return types. Could you help add those tests for view function return types?

[21Chani]

@21Chani My wrong, I should send this file for you as reference src/core/__tests__/view.test.ts. It checks ensure the return types. Could you help add those tests for view function return types?

@SamuelQZQ I didn't forget it, already started doing some tests for view function, but also encountered some challenges, busy week, moving to a new place and still have work to do, probably until sunday I can bring to you some updates 😃

[21Chani]

@SamuelQZQ I am messing with types here, and just realized the entropy is getting really huge, I'm thinking to start separated pr's for make it easy, one for slight type cleanups, another for converting structs on args and other for returning, I realized they have some slight changes, what you think?

[SamuelQZQ]

hey @21Chani , I merged you recent pr, but finally found that it cannot pass the yarn test. You can see that after that pr, the type inference of vector function arguments are broken

[SamuelQZQ]

@21Chani I have merged the other pr, please resolve conflict here

[21Chani]

@21Chani I have merged the other pr, please resolve conflict here

Awesome, I will fix this branch 🫡