Comments (3)
@grenierdev Hi, Apologies for the delay in reply, and thanks for the suggestion.
At this stage, I'm not looking to add any new functions to the Value or TypeCompiler interfaces. The recommendation today is for users to implement their own Assert functions (as you have) using a combination of Check()
+ Errors()
functions (as well as other Value processing functions if you need them).
The reasoning here is that TypeBox should only provide raw functions and guards, but not functions that use multiple internal calls to process a value (as would be the case for Assert using Check()
+ Errors()
), this is just a general design constraint TypeBox has and applies to other aspects of the library. Also, the exception thrown for an Assert is currently deferred to the user to define (which may include ALL errors for the Exception, or only the first, noting your example includes ALL errors).
For now, I'm going to keep on with this design constraint (even if the Assert does seem to make sense from a convenience standpoint). I may review in later revisions, however this would be following some additional work to TypeBox's transforms which do implicitly Assert (so there is cross over between a general Assert an Transform decode Asserts which needs a review)
Will mark this one for consideration (but may close off temporarily).
Hope this brings a bit of insights
S
from typebox.
Thanks for the lengthy answer! I understand your reasoning.
I'm just going to add that I wouldn't mind that the .Assert
doesn't use .Errors
to construct a pretty assertion error message.
Maybe it's just aesthetic. My main reason for integrating that assertion function into the library is that I wouldn't have to use separate import statements for Value.Check(...)
and Assert(...)
.
from typebox.
@grenierdev Hey, thanks for the follow up.
Maybe it's just aesthetic. My main reason for integrating that assertion function into the library is that I wouldn't have to use separate import statements for Value.Check(...) and Assert(...).
Yeah, I do appreciate the aesthetic side of things, but still need to be mindful of working outside the constraints imposed on the library. Historically, adding new convenience functions to TypeBox to simplify usage generally hasn't worked out well in the past, with particular abstractions (notably efforts to make type registration simpler (another function composed of existing TB functions)) had lead to a lot of confusion. Users will typically take on new functions as they are provided, and once they are added, it becomes very difficult remove or change them if there are problems with them (usually only identified once a function has been in the wild for a few months).
In the case of Assert specifically, as the function is a composite function (Check() + Errors()), and there is a need establish a viable AssertionError
type, I do expect some churn getting an implementation correct (the devil is in the details). Additionally, given the cross cutting concerns with Transform types asserting for non-decodable values, I'm just a bit hesitant to change things here in the short term.
For now, Ill add a consideration
tag to this issue, and investigate at a later time (post updates to Transforms), but will close the issue as out of scope (for now). The recommendation is still for users to implement their own assertion functions using the existing functions provided....but do somewhat agree the library could benefit from a simple Assert.
Hope this brings some additional insights
All the best!
S
from typebox.
Related Issues (20)
- Clean call on extended prisma result object does not work HOT 2
- esm.sh builds are broken if using FormatRegistry HOT 1
- Circular references HOT 4
- Value.Clean causes dereference error on Recursive type with nullable optional union HOT 2
- How to work with dates and timestamps HOT 2
- Issue regarding enums becoming never when using a partial deep method HOT 2
- Support for composite custom kinds HOT 1
- transform object property encoding HOT 4
- Built-in types for JSON? HOT 1
- MaxLength on keys defining a Type.Record HOT 2
- decode object with null prototype HOT 3
- Validate Enum at a low level HOT 4
- AOT compilation using custom registered types HOT 2
- Uses of BigInt over the project breaks compatibility w/ ES5 (?) HOT 3
- Typescript doesn't suggests the props using Pick or Omit HOT 1
- UUID not accpeted as string HOT 2
- How to import just Decode? HOT 4
- How to check if a schema conforms? HOT 2
- email validation doesn't work? HOT 2
- `Value.Cast` casts to wrong schema when called with union of `Refs` 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.