Comments (4)
@FDiskas @ehaynes99 Hi, Apologies for delay in reply (have been recovering from a nasty flu :( )
As a developer, I would like to use the real type in pattern - RegExp
So unfortunately, I can't really introduce this suggestion as JavaScript ECMA262 regular expressions are far more capable than what is possible to encode in JsonSchema string patterns. Some relevant documentation below with appropriate excerpt.
https://json-schema.org/understanding-json-schema/reference/regular_expressions
The pattern and patternProperties keywords use regular expressions to express constraints. The regular expression syntax used is from JavaScript (ECMA 262, specifically). However, that complete syntax is not widely supported, therefore it is recommended that you stick to the subset of that syntax described below.
So, because of the limitations here, the Type.RegExp was introduced (as a non-spec JavaScript type) that supports the full ECMA262 syntax + Unicode + the /gim
modifiers. You should consider using this type for regular expressions that step outside the bounds of what can be appropriately represented in Json Schema. Alternatively, a string format may be a better fit as that allows you to code the format as a string identifier (meaning a reciprocal user of the schema would need to implement the format accordingly)
It's not really clear to me what the RegExp type is supposed to be... Being part of the extended types, I would expect it to represent a field of type RegExp, but then if you look at the type check for it, it validates whether an input string matches the pattern, i.e. functionally equivalent to Type.String({ pattern })
You're right the RegExp type is a bit unusual. I'd drafted a little bit of information on the 0.32.0 change log about it here which makes note of the inferred type disparity when compared to the other non-standard types.
Conceptually, the RegExp type is thought of as a extremely wide TemplateLiteral type whose expressions are non-visible to the type system. In this respect, the only possible type to infer would be string
. The naming of RegExp (vs RegExpTemplate or similar) is a bit confusing I agree (particularly when contrasted with how other types are named + inferred), however I've gone with the name as it's generally easy to remember and generally signals intent. I am open to other naming schemes however.
Just on this, I am currently considering including a new Type.Refine() to the library. This has been implemented on the refine
branch and would permit RegExp implementations like the following....
const T = Type.Refine(Type.String()).Check(value => /^[a-z]*$/i.test(value)).Done()
console.log(Value.Check(T, 'abcd')) // true
This implementation is pending review and feedback, however it's introduction may enable TypeBox to potentially drop ALL extended JavaScript types in favor of refinements, as well as permit additional user defined schematics via a more ergonomic interface (better than TypeRegistry / FormatRegistry)
// user defined byte schema + check logic
const UnsafeByte = Type.Unsafe<number>({ type: 'byte' })
const Byte = Type.Refine(UnsafeByte)
.Check(value => typeof value === 'number')
.Check(value => !isNaN(value))
.Check(value => value >= 0)
.Check(value => value < 256)
.Done()
console.log(Value.Check(Byte, 0)) // false
console.log(Value.Check(Byte, 255)) // false
console.log(Value.Check(Byte, -1)) // true
console.log(Value.Check(Byte, NaN)) // true
Open to thoughts and feedback
S
from typebox.
Had too much to say about that, so created a new issue.
from typebox.
It's not really clear to me what the RegExp
type is supposed to be... Being part of the extended types, I would expect it to represent a field of type RegExp
, but then if you look at the type check for it, it validates whether an input string matches the pattern, i.e. functionally equivalent to Type.String({ pattern })
import { inspect } from 'node:util'
import { type Static, Type } from '@sinclair/typebox'
import { TypeCompiler } from '@sinclair/typebox/compiler'
const Schema = Type.RegExp(/^[a-z]$/i)
// infers: type Schema = string
type Schema = Static<typeof Schema>
const typeCheck = TypeCompiler.Compile(Schema)
console.log(inspect(Schema))
console.log()
console.log(typeCheck.Code())
outputs:
{
type: 'RegExp',
source: '^[a-z]$',
flags: 'i',
[Symbol(TypeBox.Kind)]: 'RegExp'
}
const local_0 = /^[a-z]$/i;
return function check(value) {
return (
(typeof value === 'string') &&
local_0.test(value)
)
}
I would expect the opposite of all of these:
console.log(typeCheck.Check('abCD')) // true
console.log(Value.Check(Schema, 'abCD')) // true
console.log(typeCheck.Check(/^[a-z]+$/i)) // false
console.log(Value.Check(Schema, /^[a-z]+$/i)) // false
from typebox.
@FDiskas @ehaynes99 Heya
Might close up this issue and track things over at #821. As noted above, the pattern
must be string (as that's how Json Schema encodes regular expressions) and the general recommendation will be to use Type.RegExp over String pattern. The refinement API might provide a few more options to express unicode / expression modifier options for string validation, so can track those details over at the other issue.
Cheers!
S
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
- Make `default` and `examples` schema options properties type-safe HOT 2
- 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>` HOT 7
- 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 4
- Support for async validations? HOT 1
- Transform + Map/Index does not work HOT 4
- Update the error message for required properties HOT 3
- Covariance issue with `TypeCheck<TSchema>` and `TypeCheck<TObject<{}>>` HOT 1
- Default values in nested objects are not generated HOT 2
- Doubt on Record HOT 2
- TypeCompiler compile on Type.Strict(T) - Preflight validation check failed to guard for the given schema HOT 2
- Max call stack size exceeded HOT 1
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.