implement shape types #2113
implement shape types #2113
Conversation
| T extends boolean = false, | ||
| ORDER_BY_OPTIONS extends ObjectSetArgs.OrderByOptions<L> = {} | ||
| > = PageResult<MaybeScore<Osdk.Instance<Q, ExtractOptions<R, S, T>, PropertyKeys<Q> extends L ? never : L>, ORDER_BY_OPTIONS>>; | ||
| > = PageResult<MaybeScore<Osdk.Instance<Q, ExtractOptions<R, S, T>, PropertyKeys<Q> extends L ? PropertyKeys<Q> : L>, ORDER_BY_OPTIONS>>; |
There was a problem hiding this comment.
Required to facilitate property selection for shapes
| * // player.name is string (not string | undefined) | ||
| * ``` | ||
| */ | ||
| export interface ShapeObjectSet< |
There was a problem hiding this comment.
This approach results in some duplication but I couldn't think of a better way to do this that didn't result in infinite type explosion or edits to ObjectSet typing
|
|
||
| for ( | ||
| const list of [ | ||
| shape.__requiredOrThrowProps, |
There was a problem hiding this comment.
I think it makes sense to support both of these but happy to just have one for now if we want to make things simpler
| readonly __prefetchInterfaces?: readonly InterfaceDefinition[]; | ||
| } | ||
|
|
||
| export interface ShapeDefinitionBuilder< |
There was a problem hiding this comment.
Likewise here we end up with some duplication but I think its fine here (less ideal in ShapeObjectSet)
| // If there aren't any additional properties, then we want GetPropsKeys to default to PropertyKeys<Q> | ||
| GetPropsKeys<Q, P, [R] extends [{}] ? false : true> | ||
| > | ||
| & (Q extends { __shapeMarker: { requiredProps: infer REQUIRED } } |
There was a problem hiding this comment.
We need to hook into Osdk.Instance at some point and this is the way that made sense to me. Open to other ideas though.
Adds the core types that will power shapes.
Shapes are intended to be the tool for when users want frontend-only types that are derived from ontology types but with nullability checks, certain fields applied, and OSDK operations performed on top of them. By providing a first-class way to handle this, users will no longer need to maintain many permutations of the same types.
Future PRs will use these types to implement shape behavior and functionality.
Tried to keep changes mostly constrained to the shapes package - would love more review attention to the seams where this interacts with the rest of the codebase.