Query Merge #36
Query Merge #36
Conversation
These were all basically doing the same thing - and can now all trace back and use the query call.
|
Changes I was talking about to start merging/simplifying the API calls. |
| }) | ||
| } | ||
|
|
||
| if (params.json) { |
There was a problem hiding this comment.
Hmm so it won't objectify data if json isn't true? Should we make that the default? 🤔
There was a problem hiding this comment.
Correct, the data will come back using core name types.
This isn't the json parameter passed into get_table_rows, this is kinda a new parameter that is either:
json: false(the default) the call will return core typed datajson: trueconverts all the core typed data to a plain JSON object before returning it to the app.
There was a problem hiding this comment.
Maybe we should rename this, to avoid confusion with the parameter you'd use for get_table_rows, even though it kinda does the same thing 🤔
By default, every call to get_table_rows I think will have json: false.
There was a problem hiding this comment.
Ahh ok that makes sense, I got confused because Serializer.objectify(row) doesn't do what I thought it did 😅 I think that the json param is fine here, but I guess that one other option is to have a serialize option that can take the "json" value (and potentially other values in the future??).
There was a problem hiding this comment.
I'm not sure what that'd do based on your comment, but it's definitely something we can explore! 👍
And yeah - the Serializer.objectify I think literally just calls JSON.parse(JSON.stringify()) on something to convert all the typed data (Name, Asset, etc) and makes it plain ol' JSON with strings and numbers.
Since everything's always typed everywhere on our end, I figured I'd be nice to have an option and say "give me non-typed data".
Co-authored-by: Daniel Fugere <[email protected]>
| return new TableCursor<RowType>({ | ||
| abi: this.abi, | ||
| client: this.client, | ||
| first(maxRows: number, params: QueryParams = {}): TableCursor<RowType> { |
There was a problem hiding this comment.
Should we just get rid of this .first() method like we talked about? I'm not sure it adds much value at this point since we can get the same with .query({maxRows})
There was a problem hiding this comment.
We can definitely - I wasn't sure if this still is useful as shorthand for that query though. No strong opinion.
There was a problem hiding this comment.
Yeah same here lol. I guess we can keep it around for now.
Changes:
maxRowsonquery()so it functions like the.first()call used to.first()call so it's a shortcut to usequery()instead of having its own logic.query(), it'll return an "everything" cursor likecursor()used to.cursor()call since you can just callquery()to do the same thing.QueryandQueryOptionstypes, and renamed toQueryParams(since the method is namedQueryhaving a type ofQuerywas confusing).