A get_table_row syntax comparison with eosjs, eosio-core, and the contract kit

[aaroncox]

I mentioned on today's call how I had been using the contract kit in a development version of unicove.com, and wanted to throw something together to highlight how one query has evolved for us through our apps.

We used eosjs in Anchor originally, then moved to eosio-core for Unicove, now Unicove to the contract kit. The sample below shows the syntax of all 3 for the same query we used to load delegated balances for an account.

// eosjs
await rpc.get_table_rows({
    code: 'eosio',
    table: 'delband',
    scope: 'teamgreymass',
    json: true,
})

// @greymass/eosio
await client.v1.chain.get_table_rows({
    code: 'eosio',
    table: 'delband',
    scope: 'teamgreymass',
    type: DelegatedBandwidth,
})
              
// @wharfkit/contract
await contract
    .table('delband')
    .query({
        scope: 'teamgreymass',
    })
    .all()

Each of these async calls would go out to get_table_rows and make the same request.

I'm hoping these 3 simple code samples side by side can help illustrate what this new syntax looks like and what to expect from the contract kit, at least for those of you who’d been in the trenches building against the get_table_rows APIs with us 😉

Any feedback on desirable syntax is very much welcome.

[openventures]

hey, really like the syntax obviously, the fluent interface is familiar from many other ORMs. I was wondering if the following will be valid, or if you need to specify all query paramters up front:

const userScoped = contract.table('delband').query({ scope: 'teamgreymass' });

await userScoped.query({ lower_bound: Name.from('foo') }).first();
await userScoped.query({ lower_bound: Name.from('bar') }).first();

(in this example loading the entire table might make more sense performance wise, but in other cases it might make more sense)

I was also asking myself if it would be a good idea to align the syntax a bit more with the cdt:

const tableAccessor = contract.table('delband', 'teamgreymass');

tableAccessor.all();
// or
tableAccessor.query({ lower_bound: Name.from('foo') }).all();

this would maybe also reduce the need for allowing query() chaining?

[aaroncox]

For the first example, there have been some changes over the last week dividing the old query syntax (e.g. lower_bounds, upper_bounds) vs new query syntax (e.g. to, from) that might prevent chaining like that. The example you put here though makes sense though, and I wonder if we can restore that functionality somehow 🤔

As for the 2nd part, are you just talking about renaming the Cursor to an Accessor?

The syntax you provided in the 2nd part of the post looks like it'd work in the current build. Either that or pre-coffee I'm just not seeing hte difference 😂

[openventures]

I was mainly talking about not having the scope at the same "level" as other parameters, such as lower_bound, limit, etc. but at the same level as the table name itself.

Like in the C++ cdt, you have to create the iterator like this:

auto it = delband(get_self(), "teamgreymass"_n);

it.require_find("foo"_n);

instead of:

auto table = delband(get_self());

table.require_find("teamgreymass"_n, "foo"_n);

not sure if it's really better that way tbh... just food for thought, that there is a slight mismatch in how the cdt handles this and how wharfkit is handling it.

[aaroncox]

Ahh, that might make a lot of sense to align with the syntax the CDT uses 🤔

I'll definitely raise this with the team, since it might be good to offer this option for the initial release.

[aaroncox]

This was added as an option in this upcoming PR:

wharfkit/contract@3b2e81c

It'll allow passing in the scope as the 2nd parameter, allowing for things like:

const contract = await contractKit.load('eosio.token')
const result = await contract.table('accounts', 'wharfkittest').get()

Expect it in the next release, and thanks for this suggestion!