Typechain Polkadot Grant 2

[TtomaS7]

Project Abstract

Preview

Previous Typechain W3F grant

We attempt to bring type safety to working with Polkadot contracts at the front-end side of development. Based on contracts ABIs' content, we generate corresponding runtime code in addition to TypeScript types definitions for the contracts, so that developers deal with pre-typed methods on the contract.

Generating such code automatically with CLI brings convenience to the dApps development, as well as speeds up required codebase updates, when contracts are changed in pre-release stage.

We have decided to add a new tool to the 3rd milestone that will help developers to easily integrate typechain to their projects, and it will also be compatible with Redspot (if redspot was used for compiling projects, you can just leave most of the things).

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• I have read and understood the FAQs, application guidelines and announcement guidelines.
• A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application.
• I have read and acknowledge the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.
• I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @toma.sadova:matrix.org

How Did You Hear About our grants program?

• Other: Previous successful applications for OpenBrush and Sol2Ink

[CLAassistant]

All committers have signed the CLA.

[github-actions]

The applicant has requested the discussion of the application to happen in a private chat room.

[Noc2]

Just a quick reminder here to sign the updated version of our Terms & Conditions. I will reach out via elements in case I have any other questions.

[Noc2]

Thanks for the update. I’m happy to go ahead with it. And sorry for the delay, I thought I had already approved it.

[ashlink11]

Hi @TtomaS7, this proposal is really interesting. I am excited to use this myself. However, could you double-check the total costs, which should be 97,300 by my calculations (instead of 97,000)?

[TtomaS7]

Thank you for the feedback!

oh yeah, it’s my bad...I have changed it already

[takahser]

@TtomaS7 thanks for the submission of this grant application.

I have a couple of questions:

• Is there any specific reason the daily rate is at 600.- for M3 while it is 560.- for M1 and M2?
• At M2, "3 | Contract deployment", does this mean it will be possible to generate the types directly from the *.contract file, without the need of an ABI? If so, what's the motivation behind that, since both are build artifacts, so usually there will always be an ABI if there is a *.contract file.
• At M3, "1 Precise methods definitions", what do you mean by that?
• At M3, "2 Methods' names", why don't you implement it like that directly in M2 already?
• At M3, "3 Contract classes extension", is there a reason not to include these "useful properties, normally available on the contract" already in M2?
• At M3, "4 IDE hints", what do you mean by "output typesystem"? Also, does JSDoc not just mean that you have useful inline comments to describe the types and methods, which is something you should do anyway in M2 already?
• At M3, "5 NPM Package", I assume this includes the publishing of the npm package, is that correct? If so, could you update that?
• At M3, "6 Typechain-compiler", what's the difference to the CLI provided in M2?

In general, I'm mostly fine with M2, while I think M3 looks bloated with deliveries that rather describe non-functional requirements that IMHO should be part of M2 already.

[takahser]

Suggested change

	Our main target audience is front-end and smart-contract developers of Polkadot projects.
	Our main target audience is consisting of front-end and smart-contract developers of Polkadot projects.

[TtomaS7]

• Is there any specific reason the daily rate is at 600.- for M3 while it is 560.- for M1 and M2?

Yeah, M3 has FTE:2.5 and M2 has FTE: 2
The rate of the developers are different (who will work on it), this is why I increase the daily rate

[varex83]

Thanks for your questions. We have reviewed it and made changes to our grant proposal. So check them out, please.

The reason for splitting this part up into 2 parts was to do the main work in the second milestone and then improve existing things in Milestone 3. But after our suggestion, we decided to reconstruct the Milestones.

At M2, “3 | Contract deployment”, does this mean it will be possible to generate the types directly from the *.contract file, without the need of an ABI? If so, what’s the motivation behind that, since both are build artifacts, so usually there will always be an ABI if there is a *.contract file.

We have clarified in our grant proposal that we will add availability to deploy contracts with the Constructors field, using *.contract files.

At M3, “1 Precise methods definitions”, what do you mean by that?
At M3, “2 Methods’ names”, why don’t you implement it like that directly in M2 already?
At M3, “3 Contract classes extension”, is there a reason not to include these “useful properties, normally available on the contract” already in M2?
At M3, “4 IDE hints”, what do you mean by “output typesystem”? Also, does JSDoc not just mean that you have useful inline comments to describe the types and methods, which is something you should do anyway in M2 already?

We reviewed it and decided to make it part of the 2nd milestone, so all these features aim to create a better user experience. About the Contract classes extension, we have updated the description in our grant proposal. It’s about making valuable fields and methods like withSigner or withAddress .

At M3, “5 NPM Package”, I assume this includes the publishing of the npm package, is that correct? If so, could you update that?

We are now using the GitHub registry to publish it, but we will publish it on npmjs to improve the user experience.

At M3, “6 Typechain-compiler”, what’s the difference to the CLI provided in M2?

We already have CLI since 1st milestone, but Typechain only generates code to interact with the contract, and it’s not very useful for big projects. Typechain-compiler is a tool that solves this problem: it can compile all contracts in the project, bring all ABIs and .contract files in one place and then run typechain. In the future, we will add more features to it, like a CLI wrapper to run user scripts. If you need more details regarding our next steps on Typechain, please have a look on Future plans section

Thank you for your detailed feedback and questions, it gets us more ideas on how we could improve our Milestones. I appreciate it!

[ashlink11]

Hi @TtomaS7, thanks for answering those great Qs from @takahser. I understand this TypeChain followup proposal now much better after completing your OpenBrush M6 evaluation. Firstly, the ABI JSON parser module seems like it would be very fun to build! :) Also, I would appreciate some clarity on how your tool relates to https://paritytech.github.io/contracts-ui/.

As a frontend React/Next.js dev, I know from experience it's quite complicated to understand how data comes in from the blockchain to the frontend, and may I suggest that you make some educational materials with the keywords such as "Web3 Tech Stack", "Full-stack Polkadot/Substrate dApp tutorial", "Full front-end development tutorial with Polkadot and Substrate for beginners", "As a frontend dev, how can I get data from Polkadot/Substrate blockchains to the frontend?". I actually found this current job I have because I was searching for "web3 tech stack" on google. Before that, I had watched a lecture from Next.js Conf about Next.js 12 and there was a lecture from Nader Dabit on web3 tech stacks! (also see his "complete guide" for more info) Since then, I find it's still quite complicated to onboard frontend devs & teams to the ecosystem.

Also, may I make some suggestions? The npm packaging system is quite horribly broken, but slightly less broken if you use yarn instead of npx for versioning/config/packages if that's possible for you. Facebook/Meta made/maintains yarn, for some background (and of course Facebook also created React). The creator of Node.js event loop (Ryan Dahl), even has departed from the npm ecosystem and has created the Deno ecosystem (which is intentionally incompatible with npm due to its brokenness). Deno is secure, type-safe and written in Rust. If it's possible, I think it would be very cool to see a frontend project in this ecosystem utilizing Deno (or at least on the road to eventually using it)!

By the way, I see plugins are in your future plans and I personally would like to advocate for a VSCode TypeChain plugin because I've found this IDE has the best Rust plugins. XD 🦀

[TtomaS7]

@cruikshankss Thank you so much for your review and suggestion! we will keep it on track.

[TtomaS7]

@takahser do you need any details from our side, after answering questions?

[ashlink11]

@TtomaS7 I just re-shared your application with the committee. Thanks for your patience.

[takahser]

@varex83 @TtomaS7
Thanks for the update and the clarifications and sorry for the delay here.

To me, it seems like you added 4a, 4b and 7 to M2 and updating the price from 44.8k$ to 77k$. However, imho these deliveries do not justify a price increase of >30k$. Let me explain:

• 4a Contract classes extension: tbh I'm still confused about this one in general. I know you pointed out that

  It’s about making valuable fields and methods like withSigner or withAddress

  but I'm not sure what you mean by that.

• 4b Methods' names: here you're just switching from snake_case to camelCase. While I totally support your efforts to use camelCase here, since it abides to the general TypeScript coding conventions, I don't understand why you wouldn't already include this qualitative requirement into the original implementation. So why implement it in snake_case first, only to convert it to camelCase after?

• 7 Branding: We don't usually support design work as part of a grant. Also, what exactly do you want to improve in the README? In general, I think it's good practice to update the README through development.

For these reasons, I'm fine with supporting M1 & M2 at their original price points but not at the current levels.

[varex83]

Thanks, @takahser, for your response.

• About 4a Contract classes extension is to make additional fields that will help developers interact with a contract; for example, field withSigner could change contract' signer without defining a new contract instance, so it will decrease code re-usage and make interacting with contracts easier from multi-user perspective, and also will help test contracts in the better way
• About 4b Methods' names, we decided to add 4a, 4b, and so on as sub-task because they are not such big as needed to be full tasks because they aren't time-consuming, so we moved them from the 3rd milestone to 2nd.
• About 7 README - is about adding a new logotype, gifs, and a better description of newly added features to improve the user experience. It's time-consuming and needs the involvement of our design unit. You can see how we maintain documentation in OpenBrush.

Generally speaking, soon, there will be the first commercial project that uses Typechain. FUNDRs from AllianceBlock, which already got success on Avalanche, will use Typechain and sol2ink to transpile Solidity smartcontracts' code to ink!

We are happy to hear your thoughts and speed up the process of grant acceptance!
I really appreciate any help you can provide.

[TtomaS7]

Hello, W3F team!
Let’s define how we could move forward with the grant

[Noc2]

Thanks for chasing us. I pinged the rest of the committee again.

[TtomaS7]

thank you! I appreciate it

[TtomaS7]

hello!
@Noc2 do you have any updates?

[Noc2]

I shared it again with the council. I think some council members raised concerns about the price.

[takahser]

@TtomaS7 and @varex83 thanks for sharing your thoughts. However, I think you still haven't taken any stance against my previous comment:

To me, it seems like you added 4a, 4b and 7 to M2 and updating the price from 44.8k$ to 77k$. However, imho these deliveries do not justify a price increase of >30k$.

Hence, my position is still:

For these reasons, I'm fine with supporting M1 & M2 at their original price points but not at the current levels.

[TtomaS7]

Hello!
The rate is 70$/hour for this grant, usually our grants pass from 75 to 85.

We are already started working on that and finished 60-70%, so to speed up the process, I will reduce the timelines and price.

I hope we could push it forward in near time.

[takahser]

Thanks for the update and the reduction of the price. Although I'm aware of the fact that there is still a slight premium to the original M2 price ($52.2k instead of $44.8k), I'm happy to go along with it.

[TtomaS7]

Hello, W3F team!
Do you have any updates?

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀