Metadata attached to lock requests

[ralphch0]

It would be useful to allow locks to be associated with an arbitrary metadata object. This can be used to annotate the lock request and subsequently the lock while it's held.

When a lock is requested, the metadata can be passed like so:
navigator.locks.request(
'my_resource', {
data: { /* arbitrary data..*/ }
},
async lock => {
// The lock has been acquired.
});

Later on, when querying for the lock state, the metadata is returned with the LockInfo. This would allow pages to analyze locking state by inspecting associated metadata (including what kind of lock requests are pending).

await navigator.locks.query();
{
held: [
{ name: "resource1", mode: "exclusive", clientId: "123", data: { /* arbitrary data../ } },
{ name: "resource2", mode: "shared", clientId: "123", data: { / arbitrary data../ } },
{ name: "resource2", mode: "shared", clientId: "124", data: { / arbitrary data../ } },
],
pending: [
{ name: "resource1", mode: "exclusive", clientId: "123", data: { / arbitrary data../ } },
{ name: "resource1", mode: "exclusive", clientId: "123", data: { / arbitrary data..*/ } },
]
}

Additionally, it would be nice if when when requesting a lock with "ifAvailable", the current LockInfo is returned to better understand the lock that is blocking the request. The difficulty here would be making this work with the current API shape: Callback is called with null when lock is not available.
A (not perfect) workaround here, is to call query() right after the lock request is finished.

[inexorabletash]

What are the use cases for data being more than a string? It's feasible, I just want to understand the sort of structured data that might be present.

For returning data when lock acquisition fails, how about:

navigator.locks.request(name, {ifAvailable: true, data: ...}, async (lock, data) => {
  if (!lock) {
     console.log(`failed, current holder data is: ${data}`);
     return;
  }
  ...
});

If you don't care about associated data, the API shape is unchanged.

What does data look like in the "shared" case? First holder?

[ralphch0]

I think a string should suffice. Devs can always stringify a json, I don't think the native API needs to know that the data is structured.

For the request() shape, maybe we could return (lock, currentLockHolderInfos)
currentLockHolderInfos can be an array of LockInfo, which would include the data of each lock.

[inexorabletash]

Okay. Seems like we have a plausible plan forward that doesn't require breaking changes to the API, so we shouldn't hold up launching the feature with the current shape.