TypeScript support for aepp-sdk-js to improve developer experience

Hello aeternity community,

@nikitafuchs.chain created a thread to discuss upcoming changes to improve æpp development and developer experience. There I suggested to to add TypeScript to the aepp-sdk-js to improve code completion capabilities for developers: [Spoiler Warning] User satisfaction & Dev Experience Improvement

As a first step I added the TypeScript compiler to the aepp-sdk-js and migrated two existing utils:

As a next step I would suggest creating a migration strategy to port the SDK to TypeScript with a step by step approach.

I would like to discuss the idea of adding the TypeScript compiler to the SDK as well as discussing next steps and a migration strategy. I also would like to drop stamps support since this seems to be a big issue related to code completion capabilities.

Happy to receive your feedback and discuss the ideas.

3 Likes

This is awesome !

If I may please ask thought to not make this an OOP-overkill, that would be super cool :wink: From looking at the PR, types are used just in the right dosage.

Thanks for your input. Indeed I have no plan to move everything to OOP. I would still go with the functional approach since TypeScript does not force us to use OOP.

A long term strategy I would like to drive is getting all the JavaScript to TypeScript and get rid of the stamps library. In my opinion the main reason for stamps is composing new objects and extend from multiple classes which is basically an antipattern in OOP. I would rather go with regular exports so the users can just import the functions they need.

What do you think?

cc @milenradkov.chain @davidyuk

This is a tricky thing. SDK package should be able to create instances of SDK that are aware of particular accounts/networks that should be used to sign data and requests to blockchain. SDK’s functionality should be structured somehow and it is not always enough to define it as pure functions that can be imported by the user.

Right now I would rather focus on refinking the already implemented code, I think there is a lot of stuff that can be cleaned up.

Thanks for your input.

From you message I‘m not really sure if I get it right. Are you voting for replacing stamps with regular OOP classes or for keeping stamps?

If you vote for keeping stamps we will end up using TypeScript but not exposing the types to our users and this will end up that an IDE is not able to offer IntelliSense/autocomplete for SDK functions. This would mean adding TypeScript to the SDK would then not solve the original issue users face.

The only way then is to create and maintain the type definitions (d.ts files) manually (not generate them by the TupeScript compiler). But this is quite error prone since it needs to be in sync with the actual implementation.

So from this. What would be your suggestion for a long term strategy?

What would be your suggestion for a long term strategy?

I’m voting for dropping stamps at the end (this is mostly because I’m not a fan of them, I didn’t saw them efficient). Using OOP instead, but trying to rewrite stuff in functional style before that. Currently, stamps are used in places that can be purely functional, like the generation of methods by swagger file.

Before dealing with stamps, I’m suggesting to:

  • to clean up the current state (by refactoring, removing unused code, logic fixes, reducing the package size, and so on)
  • to setup typescript where it is possible

Glad we have the same feelings on stamps and both want to drop it and use OOP instead :slight_smile:

When it comes to package size reduction I think we can also remove stuff from beeing packaged into the node module by adjusting the .npmignore file I added in the PR mentioned on the initial post.

2 Likes