-
Notifications
You must be signed in to change notification settings - Fork 547
refactor(presence): Create branded JsonDeserialized type #24641
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
base: main
Are you sure you want to change the base?
Conversation
* @system | ||
*/ | ||
export declare class JsonDeserializedBrand<T> { | ||
private readonly JsonDeserialized: JsonDeserialized<T>; |
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 can probably drop the JsonDeserialized<T>
. Just T
is probably enough. Probably want to use the dummy accessor and iterator found in that reference PR's brand classes.
const unbrandedValue = fromJsonDeserializedHandle(item.value); | ||
callbackfn(asDeeplyReadonly(unbrandedValue), key, this); |
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.
Can probably combine both of these pass-through helper functions.
const data = this.value.items[key]?.value; | ||
return data === undefined ? undefined : asDeeplyReadonly(fromJsonDeserializedHandle(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.
Kind of silly since those are both pass through anyway - should be able to adjust the helper to handle it.
f6391fb
to
1c54887
Compare
ExtensionMessage<{ | ||
type: TMessage["type"]; | ||
content: JsonSerializable< | ||
TMessage["content"], | ||
{ AllowExtensionOf: OpaqueJsonDeserialized<TMessage["content"]> } | ||
>; | ||
}>; |
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.
Temporary workaround to be reverted.
Introduce `OpaqueJsonDeserialized`, and `OpaqueJsonSerializable` as "handles" for generic values. Opaque Json types can be used when there is no direct need to work with a complex or unknown type, but still need to respect serializability. Common use is when a value that has passed through `JsonSerializable` or `JsonDeserialized` filter utilities needs to be stored, especially in a generic context. The Opaque types are recognized by `JsonSerializable` and `JsonDeserialized` allowing those stored captures to themselves be part of flow that checks for serializability or deserialization. Test cases: JsonDeserialized positive compilation tests fully supported object types are preserved ✔ OpaqueJsonDeserialized<{number:number}> partially supported object types are modified OpaqueJsonSerialized becomes OpaqueJsonDeserialized counterpart ✔ OpaqueJsonSerializable<{number:number}> becomes OpaqueJsonDeserialized<{number:number}> ✔ OpaqueJsonSerializable<{number:number}>&OpaqueJsonDeserialized<{number:number}> becomes OpaqueJsonDeserialized<{number:number}> opaque Json types requiring extra allowed types have extras removed ✔ opaque serializable object with `bigint` ✔ opaque deserialized object with `bigint` ✔ opaque serializable and deserialized object with `bigint` ✔ opaque serializable object with number array expecting `bigint` support ✔ opaque deserialized object with number array expecting `bigint` support ✔ opaque serializable and deserialized object with number array expecting `bigint` support special cases using alternately allowed types are preserved ✔ opaque serializable object with `bigint` ✔ opaque deserialized object with `bigint` ✔ opaque serializable and deserialized object with `bigint` JsonSerializable positive compilation tests supported object types opaque Json types ✔ opaque serializable object ✔ opaque deserialized object ✔ opaque serializable and deserialized object negative compilation tests unsupported types cause compiler error opaque Json types requiring extra allowed types ✔ opaque serializable object with `bigint` ✔ opaque deserialized object with `bigint` ✔ opaque serializable and deserialized object with `bigint` ✔ opaque serializable object with number array expecting `bigint` support ✔ opaque deserialized object with number array expecting `bigint` support ✔ opaque serializable and deserialized object with number array expecting `bigint` support OpaqueJsonSerializable and OpaqueJsonDeserialized positive compilation tests ✔ OpaqueJsonSerializable is covariant (more specific is assignable to general) ✔ OpaqueJsonDeserialized is covariant (more specific is assignable to general) ✔ OpaqueJsonSerializable & OpaqueJsonDeserialized is covariant (more specific is assignable to general) in a generic context ✔ OpaqueJsonDeserialized assignability varies with JsonDeserialized Options ✔ OpaqueJsonSerializable assignability varies with JsonSerializable Options ✔ OpaqueJsonSerializable may be forwarded as JsonSerializable ✔ OpaqueJsonDeserialized may be returned to JsonDeserialized ✔ OpaqueJsonSerializable & OpaqueJsonDeserialized may be returned to JsonSerializable & JsonDeserialized ✔ OpaqueJsonSerializable & OpaqueJsonDeserialized may be forwarded as JsonSerializable ✔ OpaqueJsonSerializable & OpaqueJsonDeserialized may be returned as JsonDeserialized negative compilation tests ✔ OpaqueJsonSerializable is covariant (more general is NOT assignable to specific) ✔ OpaqueJsonDeserialized is covariant (more general is NOT assignable to specific) ✔ OpaqueJsonSerializable & OpaqueJsonDeserialized is covariant (more specific is assignable to general)
Simplify internal unknown (generic) customer data that must be Json serializable using Opaque Json types At boundaries of API ins and outs, Json filtered types are cast to/from Opaque Json types. See new helpers: - `fullySerializableToOpaqueJson` - `asDeserializedJson` - `asDeeplyReadonlyDeserializedJson` Notifications utilities are updated and removal of `string &` for `NotificationListeners` allowed clean up of `@ts-ignore-error`. `NotificationsManagerImpl`'s `emit` implementation now just types `name` to `string`.'
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output
|
Updates the presence internals to use a branded internal type when passing around JsonDeserialized objects. There are two functions to brand and unbrand a JsonDeserialized object.
Externally, the API remains the same; the internal types and functions are marked
@system
and objects are converted between the types at the API boundaries.