Small contributions

Almost all coders aren’t well-documented. I wanted to know if I could document it.

2 Likes

Hey @miguel, what kind of information do you think you could benefit from? I am actually currently working on this PR which will give a general overview to our approach to encoding in the SDK - I’d be keen to get your feedback. We are also currently in the design phase of a refactor of the abi-coder package so do know the implementation details of the coders themselves may change.

1 Like

Hmm, I didn’t know that. Initially, I would start by documenting the code. Furthermore, we could abstract these validations present at coders - I’m not sure whether all coders have the same validation.

Here’s the validation:

    if (!Array.isArray(value)) {
      throw new FuelError(ErrorCode.ENCODE_ERROR, `Expected array value.`);
    }

    if (this.length !== value.length) {
      throw new FuelError(ErrorCode.ENCODE_ERROR, `Types/values length mismatch.`);
    }

Currently, OptionCoder doesn’t has tests.

Agreed the validations should be abstracted away, this is one of the criteria for the refactor.

The OptionCoder shares a lot of logic with the EnumCoder. As you can see from the code it extends that class as from a TS perspective an option can be interpretted as an enum with 2 keys, None and Some. The OptionCoder itself just provides top level transformations rather than any encoding logic. So the core logic is tested enum side. We also have plenty of feature tests for options in our integration test directory, fuel-gauge. But if you would like to contribute some unit tests, that would be appreciated.

Have you already started the refactor?

Btw, I’m with a problem creating a sut (system under test) in the case of native enums

No it is currently in the design phase, feel free to comment any suggestions on the issue.

What issue are you having?

Could I speak to you directly? (discord or twitter)

I need to simulate a native enum :slight_smile:

I do prefer keeping things public on forum or issues as it’ll also benefit others that have the same issue.

We’ve got some test cases for them in our integration testing suite: fuels-ts/packages/fuel-gauge/src/coverage-contract.test.ts at be92daf9d69eee8f905ec2d3974ea03995baa0b7 · FuelLabs/fuels-ts · GitHub

When will coder refactoring begin?

Not sure currently, it is not something we will do before mainnet. If you have any thoughts, feel free to summarise them on the refactor issue.

1 Like

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.