search

FuelLabs / fuels-ts

Fuel Network Typescript SDK
https://docs.fuel.network/docs/fuels-ts/
Apache License 2.0
44.1k stars 1.34k forks source link

Refactor `ABI Gen` package #2877

Closed arboleya closed 1 month ago

arboleya commented 2 months ago

TBD

nedsalk commented 1 month ago

There are several goals of the refactor:

  1. Merge the abi-coder and abi-typegen packages into one. #2346
  2. Create an abstraction on top of JsonAbi which abi-coder and abi-typegen can build on, so that changes to the abi specification are localized to that abstraction while coders and typegen remain unaffected.
  3. Possibly have the approach to interpreting that abstraction be the same in coder and typegen and going from abstraction to coder/typer be the same
  4. Refactor typegen "typers" (IType interface implementers)
  5. Figure out a better coder design. #1795

Items 1-4 can be done immediately because they're internal details, whereas item 5 must be left for v1 because all the coders are currently exported to the users.

Pre-v1

1. Merge the abi-coder and abi-typegen packages into one.

This is a straightforward task and should just require putting the two packages together into a single abi package (coder and typegen folders) and removing the duplicate code: JsonAbi interfaces and the abi transpiler.

2. Create an abstraction on top of JsonAbi

This was already done in https://github.com/FuelLabs/fuels-ts/pull/2826 with the ResolvableType and ResolvedType abstractions. The goal of this item would be to update the folder structure of the abi package src now has three folders: parser, coder and typegen. The abstraction would go into the parser folder. The coder and typegen implementations would then reference the abstraction in appropriate places. Inspiration can be taken from the referenced PR.

3. Interpret the abstraction the same way in typegen and coder

This is related to how we go from the abstraction to a specific coder/typer. The coder does this via the getCoder function, while typegen does it via the parseType function. The difference between them is that suitability of a coder for a specific type is determined in the getCoder function directly, whereas in typegen each type has an isSuitableFor(type) static method which checks for suitability of that specific type. Both approaches are okay and easy to digest and working on this gives the least bang for the buck out of all the items.

4. Refactor typegen "typers"

After working with abi-typegen extensively in https://github.com/FuelLabs/fuels-ts/pull/2826 I realized that the IType interface and its implementers can be simplified after introduction of the abstraction from item 2. The changes can be seen in the referenced PR, but they boil down to immediately resolving input and output labels upon instantiation, having only fields on IType and no methods that have to be called for additional post-processing. Please note that the referenced PR's implementation falls short from this in some aspects and should be improved upon, but is a step in that direction.

We should also reevaluate the need for some tests in typegen at this point because they'll start breaking once the refactoring commences. I believe that it is enough for us to have the full sway project be the exhaustive source for verifying input and output label correctness of all types via this test and that we don't need tests for each "typer" individually.

v1

5. Figure out a better coder design

Info on this can be found in https://github.com/FuelLabs/fuels-ts/issues/1795.

arboleya commented 1 month ago

Closing in favor of: