fix(client-presence): [BREAKING CHANGE] LatestMap keys limited to strings

[jason-ha]

Remove number as a possible type for LatestMap keys. All given keys are stored as string record entries at runtime and thus numbers become keys. To use "number" keys, string pattern ${number} can be used for the type.

Add keyValidator to support enabling consumers to only work with validated keys. A keyValidator is recommended anytime Keys type is not string.

[tylerbutler]

If I understand correctly, there's no way for a user to access or enumerate keys for which the validator returns undefined. I can understand this behavior for iteration, but it seems odd that .get(invalidKey) is the same as .get(missingKey). In practice maybe that distinction doesn't matter much.

[tylerbutler]

Do we want to keep this optional long-term? If I recall correctly, we decided to make the main validator required since we believe it's best practice to use runtime validation in addition to the compile-time. I can understand how key validation might be more optional, but do we lose any compile-time help with this approach?

[jason-ha]

I was thinking that it can stay optional. We can guarantee that keys are string | number. Key validator would only be useful if you wanted to reduce from there.
With the new proposal to return a boolean, we can actually change the signature to keyValidator(key: string | number): asserts key is Keys. When not provided, there wouldn't be anything to infer the Key type, but it should work when provided. I think the optionality won't matter. I will confirm.

[jason-ha]

If I understand correctly, there's no way for a user to access or enumerate keys for which the validator returns undefined. I can understand this behavior for iteration, but it seems odd that .get(invalidKey) is the same as .get(missingKey). In practice maybe that distinction doesn't matter much.

Good question. With a keyValidator, the difference would be that the keyValidator would be invoked. So, it could be written to snoop whether something was invalid or missing.
I think we'll need to see if there is desire for something nicer.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  249533 links
    1776 destination URLs
    2013 URLs ignored
       0 warnings
       0 errors