Proposal: Add adapter base class

[toozol]

Background

While playing around with the new example added for the Virtuals G.A.M.E framework in #207, I noticed that we're essentially embedding a new adapter inside the example.

Then it got me thinking that, in essence, every adapter performs the following steps:

• Takes in a list of "GOAT tools"
• Converts each "GOAT tool" to a tool understandable by the target framework
• Returns the converted list of tools

What does this PR do?

I think it could be beneficial to have an adapter base class which has:

• An abstract method which users can implement to define the logic for converting a tool for a given target framework
• A concrete method which takes in the list of "GOAT tools" and returns the list of converted tools

An example implementation would be what I added in this PR:

• Add a new GAME adapter: VirtualsGameAdapter that extends AdapterBase
• Call await adapter.getAdaptedTools(); in the GAME example to get the list of converted tools

Benefits

• Standardization of adapter creation
• Less duplicate code (every adapter maps through tools and converts them for the target framework)

Next steps

If this PR is approved, I can change existing adapters to leverage the new base class.

Testing

There should no change in functionality. I only refactored code related to adapter usage.

Discord username

toozol1

[changeset-bot]

⚠️ No Changeset found

Latest commit: 70ac0ee

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[0xaguspunk]

Hey @toozol :) ! Thanks for the PR. I think we already have this in some way, the only thing here is we didn't implement the adapter for GAME since it's an early version of their SDK and likely to change in the next days/weeks.

Other adapters follow the same approach, the idea with the getTools function is having that common interface between all adapters, then it's up to them to adapt the tools they get to the specific framework. All adapters implement a getOnChainTools function for consistency :)