Comments (11)
@darkobits My main point is that label()
is in the wrong place. If we were to keep it fluent, it should be ow.label('foo')(foo, ow.string);
instead, but that doesn't look very good.
from ow.
Yeah, I had overlooked this case; I just wanted to make sure you guys were onboard before submitting a PR. :)
from ow.
Just an oversight I think.
@transitive-bullshit Thoughts?
from ow.
Go for it :)
from ow.
I now come to realize adding .label()
to the types were a mistake. The label has nothing to do with the predicate. It should be a top-level thing. Having it on the type also lets the user specify it anywhere in the chain, which results in unreadable code if multiple assertions have the label in different places (I'm sure some users will do that).
It would have made more sense to add it top-level:
ow(foo, 'foo', ow.string);
This would also solve my comment in #92 (comment).
@SamVerschueren @transitive-bullshit Thoughts?
from ow.
I agree that after using it for a while, the .label()
makes the predicates quite heavy to process mentally. The only thing we should make sure off is that users don't expect ow(foo, 'bar', ow.string)
to validate foo.bar
. That's what the API of SinonJS does for instance, sinon.spy(foo, 'bar')
spies the bar
function on the foo
object. But I think it makes sense to do it this way.
In the discussion we had about this we had to make a decision because there where many opinions but if we feel like it doesn't really work out, we should refactor it.
from ow.
The only thing we should make sure off is that users don't expect ow(foo, 'bar', ow.string) to validate foo.bar. That's what the API of SinonJS does for instance, sinon.spy(foo, 'bar') spies the bar function on the foo object.
I don't really see why people would expect that. The person coding it would hopefully read the docs, and the ones reading it would see ow(foo, 'foo')
, which doesn't look like property access.
Regardless, with #98, the label would only be needed to be set manually if you want it in production minified in the browser, which I think few would want anyway. So in the end, this doesn't matter much.
from ow.
This would definitely be an 🕶addition to this package.
As an aside, I'm not too particular about which route you guys decide to go, though simply adding support for .label()
to .any()
would be a non-breaking change and, in my humble opinion, be more in line with the current "fluent API" approach that ow
uses.
Whether or not you want to keep that design or move to the parameterized approach seems like it may be better suited to a separate discussion.
Either way, keep up the good work! 😸
from ow.
Guys are you planning to do something with this?
from ow.
PR welcome for my proposal in #89 (comment) :)
from ow.
I'm working on this
from ow.
Related Issues (20)
- Bug: `isValid` wrong typing HOT 3
- Package does not seem to work on node v8 `SyntaxError: Unexpected token {` HOT 1
- string.nonBlank validator HOT 1
- Error running with metro bundler
- generate objects from predicate HOT 3
- use browser-side HOT 1
- Unclear error message when checking NaN against the number type HOT 7
- Composition HOT 3
- Is there a way for an object predicate to differentiate between key with value `undefined`, and key not present? HOT 2
- should `ow.string.equals` be narrowing the type to specific strings? HOT 1
- wrong message: Expected `e` to be of type .... - instead of Expected argument to be of type HOT 3
- Show all possible errors exhaustively (option?)
- const values HOT 1
- Q: how to make custom type narrowing validator (i.e. Predicate<x>)? HOT 3
- metadata
- Documentation is 404
- Build errors when using ow in React app compiled with vite
- Upgrading to 1.1.0 from older version makes TS complain HOT 6
- correct pattern for optional 'required' properties?
- Cannot find module 'ow' or its corresponding type declarations HOT 6
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 ow.