See the 1.0 milestone for a full list of fixes and features planned for 1.0.
Listed below are features that are planned for the 1.0 release. The goal is to have a 1.0 release candidate with all these features by Q1 2019, but this may change depending on community feedback and support.
Tracking this feature in issue #4
A proper test suite is crucial for developers to build secure and correct smart contracts.
EOS already supports unit tests for smart contracts (see
eosio.contracts for an example), so to support this in Rust we will likely need to:
- Generate more FFI bindings for EOS libraries.
- Create a new
eosio_testcrate that will be a test harness, similar to how
wasm-bindgen-testto support testing in headless browsers.
Tracking this feature in issue #5
Hand-written ABI files are unnecessary and expose developers to risk if they aren't kept updated.
Since we already have
#[eosio::table] attributes, it should be fairly straightforward to implement this feature by detecting these attributes and generating a JSON file.
ABI to Rust
Tracking this feature in issue #6
It would be nice to have a CLI command that would generate Rust code from on-chain ABIs. This would make it significantly easier to interact with external contracts through inline actions.
Implementing this feature would require fetching the ABI JSON from an EOS node and creating a Rust file containing the generated tables and actions.
Tracking this feature in issue #7
Making changes to EOS table fields is currently not a pleasant experience. It can be a fragile error-prone process that involves duplicating code to work with multiple versions of structs. We believe that a better solution can be found by taking inspiration from projects like Diesel and Django migrations.
Implementing this feature will require significant effort and discovery. This may be a 1.0+ feature.
Tracking this feature in issue #8
eosjs, and something similar should exist for Rust.
Implementing this will be tricky since we need to support browser and server environments.
This could get even more complicated if we decide to optionally support futures. For the initial release futures will probably be mandatory.
There are a lot of things to consider so this may be a 1.0+ feature.
Tracking this feature in issue #9
We already have several features that need CLIs. Consolidating all our CLIs under one CLI will make things simpler for developers and allow us to add new commands later on.
Commands should be implemented to:
- Create a new
- Generate an ABI file, e.g.
- Generate Rust from an ABI, e.g.
- Manage table schemas, e.g.
- Run unit tests, e.g.
Tracking this feature in issue #10
A big selling point of Rust is its first-class support for WebAssembly and the possibility of writing full-stack web applications in one highly performant language. It would be great if we could use the same structs and functions from our smart contracts in our frontend code as well.
Implementing this may require rethinking some things, specifically traits that are implemented on primitive types like
SecondaryTableKey seem to be causing some issues.
Tracking this feature in issue #11
Serde is the defacto standard when it comes to serializing and deserializing data. It will be necessary for table structs to support Serde's
Deserialize traits in order to implement the RPC API later on.
Implementing this will require writing custom serializers/deserializers for EOS types, for example:
- Booleans are 0 or 1
- Large numbers can sometimes be integers, sometimes be strings