-
Notifications
You must be signed in to change notification settings - Fork 47
[RSDK-10123] user defined metadata crud apis #477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/app/app-client.ts
Outdated
* @param id The ID of the robot | ||
* @returns The metadata associated with the robot | ||
*/ | ||
async getRobotMetadata(id: string): Promise<GetRobotMetadataResponse> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mix/match prepending the type of object to Id
: locationId
and organizationId
, but just id
for robot
and robotPart
. Let's try to be consistent? Even if the proto has different names, we can make the user-facing API consistent.
I don't mind one way or the other, maybe a slight preference to just id
everywhere since the object is already specified in the method name, but I'm never against hyper-specificity if you want to do robotId
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which actually brings up another question -- do we want to call it robot
or machine
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for calling this out - I agree we should be consistent, let's go with id
!
My gut tells me robot
because that's what we called it on the protos end of things, but what do you think?
If you prefer machine, that is fine by me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to ask @JessamyT here for docs perspective: should we be using robot
or machine
? Most other functions are still using robot
, so do we try for consistency, or do we start the migration to machine
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My uninformed inclination is to migrate towards machine
since we do use that everywhere throughout the docs, even when talking about SDKs that use robot
. Like we basically say robot = machine
all over the place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good - thanks for chiming in!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(drive by comment since I'm referencing this for RSDK-10138)
I'm wondering if we actually want to use "machine" here right now. Like we pointed out, all other methods in this sdk (and the Go one) are centered around "robot", so as a new user, I'd find myself kinda confused as to why they're mixed (I have to reference our glossary from time-to-time to remind myself of the relationship between machines/robots, parts, components, etc).
IMO from a purely UX perspective, it would be clearer to continue with "robot" for consistency. We could add a docs note reminding users that robot = machine
and eventually rename the methods all at once, probably with an interim deprecation. I'm still new to the ethos/process behind this, so totally okay if that's beyond our usual scope of effort!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see that being useful. particularly when searching for functions, you could try to do a find for robot
and see all the functions available on a robot. @JessamyT can we call this robot
and then to a formal migration when we're ready to rename everything to machine
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small suggestion, otherwise looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two comments I left are applicable to all methods added
src/app/app-client.ts
Outdated
): Promise<GetOrganizationMetadataResponse> { | ||
return this.client.getOrganizationMetadata({ organizationId: id }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should return a dictionary here. Since the rpc returns a Struct
, we should be able to convert that Struct
into a native JS obj to make it easier for users to work it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do things look good as I have them now? I am having a really hard time getting the unit tests to pass (not too familiar with typescript)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps instead of using unknown
you could use JsonValue
or any
(JsonValue
would be more specific)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JsonValue
works! Thanks!
src/app/app-client.ts
Outdated
*/ | ||
async updateOrganizationMetadata( | ||
id: string, | ||
data: Record<string, Any> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, we should take in a record of string to lowercase any
(the typescript type), and then convert that into a pb.Struct
so that it's easier for the user to use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(left one comment that I want to make sure we're clear on, otherwise nothing that's blocking from me)
081d380
to
72f92f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to pull from main and regenerate the protos (using make build-buf
) because it looks like your branch is still using the map<string, Any>
proto definition rather than the Struct
one
src/app/app-client.ts
Outdated
* @returns A record whose keys match `data`, | ||
* with values unpacked from Struct messages | ||
*/ | ||
export const decodeMetadataMap = (data: Record<string, Any>): Record<string, JsonValue> => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still needed? I don't believe we're using protobuf.Any
anywhere now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope! thanks for clarifying
src/app/app-client.ts
Outdated
id: string | ||
): Promise<Record<string, JsonValue>> { | ||
const response = await this.client.getOrganizationMetadata({ organizationId: id }); | ||
return decodeMetadataMap(response.data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should just be able to return response.data.toJson()
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, that basically works - needed to convert it to Record<string, JsonValue>
src/app/app-client.ts
Outdated
const convertedData = new Struct({ fields: {} }); | ||
for (const [key, val] of Object.entries(data)) { | ||
convertedData.fields[key] = Value.fromJson(val); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similarly, i don't think you have to convert any fields, just use Struct.fromJson(...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, thanks!
6a71c4b
to
4723a36
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM % a couple docstring tweaks
src/app/app-client.ts
Outdated
* Updates user-defined metadata for a machine robot. | ||
* | ||
* @param id The ID of the machine robot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Updates user-defined metadata for a machine robot. | |
* | |
* @param id The ID of the machine robot | |
* Updates user-defined metadata for a robot part. | |
* | |
* @param id The ID of the robot part |
src/app/app-client.ts
Outdated
* Retrieves user-defined metadata for an organization. | ||
* | ||
* @param id The ID of the organization | ||
* @returns The metadata associated with the organization as a plain JS object |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @returns The metadata associated with the organization as a plain JS object | |
* @returns The metadata associated with the organization |
The other docstrings don't mention this so I think we can remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for calling this out!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!! Thanks for all the updates.
For future reference, you could also do something like this so that you aren't doing the same cast over and over again:
return (response.data?.toJson() as JsonObject) ?? {};
Description
Add user-defined metadata CRUD operations
See ticket here
Todo