Closed nicholasfinos closed 6 months ago
@nicholasfinos Hi,
I was wondering if there were any plans to work on JSON schema dependencies and/or oneOf in Typebox?
Possibly, but not in the short term. As it stands, Intersect -> AND
, Union -> OR
, and UnionOneOf -> XOR
. The main thing holding back an implementation of OneOf is that in TypeScript, there isn't support for an XOR type operator, meaning there is no direct correspondence between the semantics of OneOf and what can be adequately expressed in the TypeScript language at a type level.
The closest approximation of OneOf would simply be Union (as per reference prototype implementation), however a more correct implementation would be to generate a Never
schematic if the constituents of the OneOf had potential for more than one match. Consider.
type T = string ^ string // T is never (imaginary ^ as xor operator)
const T = Type.UnionOneOf([ // this schema is illogical as passing a string
Type.String(), // would fail due to multiple matches, and not
Type.String() // passing a string would fail also, making the
]) // only reasonable type TNever
If TypeBox were to implement OneOf, it would need to have the characteristics above (i.e. detect structural overlap and yield never for illogical cases), however the complexity and compute cost deriving this for more complex types is currently unknown and presumed prohibitively expensive for more complex data structures with constraints (but the project welcomes community experimentation trying to compute the type)
were there any work arounds that people have been using?
Yes, as mentioned, if you need OneOf, you can use the UnionOneOf implementation (but mindful not to construct an illogical schema). However you will need to include this as a module somewhat in your project.
import { TypeRegistry, Kind, Static, TSchema, SchemaOptions } from '@sinclair/typebox'
import { Value } from '@sinclair/typebox/value'
// -------------------------------------------------------------------------------------
// TUnionOneOf
// -------------------------------------------------------------------------------------
export interface TUnionOneOf<T extends TSchema[]> extends TSchema {
[Kind]: 'UnionOneOf'
static: { [K in keyof T]: Static<T[K]> }[number]
oneOf: T
}
// -------------------------------------------------------------------------------------
// UnionOneOf
// -------------------------------------------------------------------------------------
/** `[Experimental]` Creates a Union type with a `oneOf` schema representation */
export function UnionOneOf<T extends TSchema[]>(oneOf: [...T], options: SchemaOptions = {}) {
function UnionOneOfCheck(schema: TUnionOneOf<TSchema[]>, value: unknown) {
return 1 === schema.oneOf.reduce((acc: number, schema: any) => (Value.Check(schema, value) ? acc + 1 : acc), 0)
}
if (!TypeRegistry.Has('UnionOneOf')) TypeRegistry.Set('UnionOneOf', UnionOneOfCheck)
return { ...options, [Kind]: 'UnionOneOf', oneOf } as TUnionOneOf<T>
}
const T = UnionOneOf([
Type.String(),
Type.Number(),
Type.Boolean(),
])
However, in most cases, it's generally just easier to use Union (anyOf)
TypeBox may implement these (starting with If/Else/Then schematics) when it makes a shift to the draft 2012-12 specification. You can use conditional / dependent schemas today (using similar techniques above, or just using Unsafe), however you will need to use Ajv to validate (as the TypeBox compiler will only check for constructs it can represent).
Hope this helps! S
@nicholasfinos Hiya,
Might close off this issue as UnionOneOf isn't planned as a standard type for the reasons noted above (at least in the near term). But if you need some help expressing this type (or the dependencies keyword) using TypeBox, feel free to ping me on this thread. Can provide additional assistance if you need.
All the best! S
@nicholasfinos I believe for your use case, something like this might work
const formValues = Type.Union([
Type.Object({
state: Type.Literal('State 1'),
region: Type.Union([Type.Literal('Region 1'), Type.Literal('Region 2')])
}),
Type.Object({
state: Type.Literal('State 2'),
region: Type.Union([Type.Literal('Region 3'), Type.Literal('Region 4')])
})
])
Not sure if this is related, but after looking around and not finding much for what I'm attempting to do, I stumbled on a solution that solves my particular case of allowing one key or another key only pretty well. The particular case is in allowing one key or another and never both keys (XOR) and it can be achieved by doing this:
const extraCond = Type.Union([
Type.Object({ param1: Type.Any(), param2: Type.Optional(Type.Never()) }),
Type.Object({ param1: Type.Optional(Type.Never()), param2: Type.Any() }),
])
For my use case on creating recurrence objects for scheduling events, I do something like the following which seems to work well, Intellisense and fastify schema validation seems to work as expected
const dailyCondition = Type.Object({
interval: Type.Number(),
freq: Type.Literal('daily'),
})
const weeklyCondition = Type.Object({
interval: Type.Number(),
freq: Type.Literal('weekly'),
byDay: Type.Array(Type.String()),
})
const monthlyCondition = Type.Union([
Type.Object({
interval: Type.Number(),
freq: Type.Literal('monthly'),
byMonthDay: Type.Number(),
}),
Type.Object({
interval: Type.Number(),
freq: Type.Literal('monthly'),
byDay: Type.Array(Type.String(), { minItems: 1, maxItems: 1 }),
bySetPos: Type.Number(),
}),
])
const endOnCondition = Type.Union([
Type.Object({
count: Type.Optional(Type.Never()),
until: Type.Optional(Type.Never()),
}),
Type.Object({
count: Type.Number(),
until: Type.Optional(Type.Never()),
}),
Type.Object({
count: Type.Optional(Type.Never()),
until: Type.String({ format: 'date-time' }),
}),
])
const recurrence = Type.Intersect([
Type.Union([dailyCondition, weeklyCondition, monthlyCondition]),
endOnCondition,
])
I was wondering if there were any plans to work on JSON schema dependencies and/or oneOf in Typebox? I am trying to build a JSON schema form with nested dependencies whereby the value of a state field determines the potential values of a region field which determine the value of an area field (assuming the values for each of these fields are sets of enums.
From poking around the repo issues, I’ve seen that there have been a few requests for this previously and there is a prototype for UnionOneOf but hasn’t been a priority due to the difficulty to implement.
Were there any plans to continue working on this? If not were there any work arounds that people have been using? Currently, I’ve been working around this by adding the dependencies as a custom field on the parent object hack the types for it by defining them and having a custom field to ignore them when rendering my form (see below) but was hoping that I could define something a bit less hacky.