Hello, and welcome back to another progress update. Developers, rejoice — this time around, everything we’ve been working on is for you! From an update to the Antelope library to major progress on Wharf Kit, we’ve been working with single-minded focus on ways to make the development experience better on all the Antelope blockchains. More details below.
Session Kit
V1.0 of the Session Kit is Live + Some Bonus Releases
Almost exactly a month ago, we released v1.0 of the Session Kit. This is a major part of Wharf Kit, since it simplifies the development process when allowing users to log into a web application and sign transactions with their wallet. It also helps with beginning, ending, and persisting sessions.
In order to help developers find success with the Session Kit, we simultaneously released:
- The Web Renderer, which provides an out-of-the-box user experience.
- 4 sample projects that illustrate how Wharf integrates into popular web frameworks.
- 4 wallet plugins, which allow users to access apps with their preferred wallet.
- 4 transact plugins that make performing transactions on Antelope blockchains easier.
- 3 plugin templates, which allow developers to extend the Session Kit.
In addition, the Wharfkit.com website got a considerable facelift, with multiple new pages and in-depth documentation for the Session Kit.
See the Session Kit in Action
If you’d like to learn more about the Session Kit, then we highly recommend signing up for our joint webinar with the ENF, A New Way to Build Web Apps on Antelope:
Getting Started With the Wharf Session Kit. During the webinar, Aaron Cox will give a hands-on demonstration of how to use the Session Kit to add wallet log-in functionality to an existing web app.
Wombat Wallet Plugin Release
Speaking of log-in functionality, when we released v1.0 of the Session Kit, we provided two plugins to make logging in work seamlessly with the Anchor Authenticator and MyCloudWallet.com. We’re excited to announce that the plugin for the Wombat wallet is now ready as well, providing developers with a third wallet option.
Updates to the Wharf Web Renderer
In the last bit of news for the Session Kit, our designer has been working on optimizing the Web Renderer that provides an out-of-the-box interface when users connect their wallets to a web application. It now includes a minimal mode that developers can toggle to hide any elements that aren’t strictly necessary, and comes with an enhanced dark mode option.
Contract Kit
The Contract Kit, when it’s complete, will make it easy to access and utilize smart contract data when building web applications, simplify the process of creating transactions, and perform automatic code generation for any smart contract to provide scaffolding for later development.
Technical Preview
Last week, we released a Technical Preview that’s based on v0.4.x of the Contract Kit. This early version of the kit allows developers to dynamically load [Contract] class instances, create actions to use in transact calls, and access table data in a new and simplified way.
We encourage developers to try out these components of the Contract Kit, and let us know if they find any issues or if anything is unclear in the three guides that are provided in the Technical Preview. We can be reached both in the Wharf Telegram channel and on the Github discussion boards.
CLI Beta
On August 28th, we released the code generation component of the Contract Kit to the public, in order for developers to start using it and provide feedback. This is a command line tool that can considerably reduce the coding required when you’re building on top of a smart contract, so we hope that developers in the community will try it out and let us know how it goes.
A few important things to note:
- Currently the CLI’s only command is [generate] which is used to create Typescript code automatically from a deployed smart contract.
- This is a raw Node.js script that can be installed globally. If there’s demand, we may later release it in a form that doesn’t require npm/Node.js.
- The code it generates will work with Contract Kit v0.4.2.
In Other News…
Antelope Library 0.8 Release
Before we dive into what’s new with the Antelope library, let’s first do a quick recap: In case you missed it, we mentioned in our May progress update that we moved the EOSIO Core library from under the Greymass organization to become a part of Wharf. We also renamed the library from EOSIO to Antelope in order to better reflect the protocol’s brand change. For developers, this change means the “@greymass/eosio” library has now become the “@wharfkit/antelope” library.
And now we’ve got that cleared up, on to the exciting part! Two weeks ago, we released v0.8.0 of the Antelope library, which includes multiple improvements:
- When looking up account authorizations on the blockchain, developers can now choose between using the account name or the associated public keys. Previously, looking up accounts could only be done with keys.
- Previously when developers retrieved information on an account, voter information would be missing for accounts on both Telos and WAX. We’ve fixed this problem, and are looking into more scalable ways to resolve blockchain-specific API issues (more on that in a moment!)
- By default, the Antelope library now compresses all packed transactions. While developers can opt out of this, we highly recommend compressing transactions because it reduces the NET resource cost of transactions and also reduces server bandwidth usage. For more information on this change, you can check out the Github Discussions post on it here.
Future Antelope API Improvements
Looking to the future, we’re currently exploring ways to make the API client in the Antelope library more tailored to the specific types of data provided by the different Antelope blockchains, since the original EOSIO Core library was created only with vanilla EOSIO implementations in mind. This leads to occasional issues, such as the lack of Telos and WAX voter information mentioned above.
Our goal is to create chain-specific variations of the API client that would automatically switch based on which blockchain a developer is querying, in order to prevent the gaps in data that can occur when developing on non-EOS blockchains.
While we don’t currently have a target release date for this change, we wanted to let the wider developer community know that it’s in the works and that any thoughts on the subject are welcome.
And that’s all for now, folks! Stay safe out there, and we’ll see you in the next progress update.
