Comments (2)
@Not-Jayden Hi, thanks for the suggestion.
Unfortunately, this is considered to be out-of-scope as the default
and examples
annotations are not required to match that of the type. There are actually cases where external tooling can use these keywords to perform custom processing of a schematic (inclusive of assigning functions that return type values lazily).
There are some notes on this at the following URL
https://json-schema.org/understanding-json-schema/reference/annotations
The default keyword specifies a default value. This value is not used to fill in missing values during the validation process. Non-validation tools such as documentation generators or form generators may use this value to give hints to users about how to use a value. However, default is typically used to express that if a value is missing, then the value is semantically the same as if the value was present with the default value. The value of default should validate against the schema in which it resides, but that isn't required.
So, from the above, making these keywords strictly match the type means that users who need to assign other values there (for the purposes of tooling) would no longer be able to do so. It was generally decided that TB should let any value be assigned.
Hope this brings some insights. Will close off this issue for now, but if you have any follow up questions, feel free to post on this thread.
Cheers
S
from typebox.
@sinclairzx81 Awesome, thanks a lot for sharing that context and for getting back to me so quickly!
Looking at the docs, should the examples
type at least be changed to any[]
maybe?
The value of this keyword MUST be an array. There are no restrictions placed on the values within the array. When multiple occurrences of this keyword are applicable to a single sub-instance, implementations MUST provide a flat array of all values rather than an array of arrays.
Also skimming the docs further, they also specify for the default
property
It is RECOMMENDED that a default value be valid against the associated schema.
and for the examples
property
It is RECOMMENDED that these values be valid against the associated schema.
With that in mind, I wonder if it would still be reasonable for it to be type safe by default with a means of opting out of the strict types if needed (maybe via conditional types or overloads), given it should be an exception to the rule that you don't follow the recommendation.
That said I understand this might not be considered overly important for the amount of complexity it adds to support, I just wanted to make sure the decision is well considered.
For some additional context, I'm particularly flagging this because I was considering to start using Value.Create()
for mocking purposes inside a large shared codebase, but it feels fragile that defaults are going to inevitably be defined incorrectly.
const numSchema = Type.Number({default: "Psyche this isn't a number"})
const mockNumValue = Value.Create(numSchema); // TS thinks this is a `number` but it's just the default string value
Keen to hear your thoughts :)
from typebox.
Related Issues (20)
- Should `IsValueType` guard consider `Date`? HOT 1
- ESNext target HOT 3
- Trying to do codegen from Drizzle schemas HOT 1
- Indicate which files don't have "sideEffects" in package.json for improved tree shaking HOT 3
- Type.String().Optional() is accepted on ts-hint / ts-lint, and even build successfully; but of course, "Optional()" does not exists HOT 2
- Dynamic Template Literals can't be Mapped HOT 2
- How should TypeBox types be used with TS type predicates? HOT 2
- TypeCompiler.Compile incorrectly parsing `Record<any, any>`
- Error when using Composite with Ref (Unable to dereference schema with $id 'undefined') HOT 3
- Transform type keys in Record HOT 2
- Is it possible to add support to the Type.String additional properties for the enum keyword HOT 2
- Support for async validations? HOT 1
- Transform + Map/Index does not work HOT 4
- Update the error message for required properties
- Covariance issue with `TypeCheck<TSchema>` and `TypeCheck<TObject<{}>>`
- Default values in nested objects are not generated HOT 1
- Doubt on Record HOT 2
- TypeCompiler compile on Type.Strict(T) - Preflight validation check failed to guard for the given schema
- Max call stack size exceeded
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typebox.