Get feedback from at least 5 people to make sure it's ready to release 1.0

[wookieb]

Get feedback from at least 5 people to make sure it's ready to release 1.0

[jpospychala]

nice library, nice docs, API seems simple.
Reminds excellent Ramda (http://ramda.github.io/ramdocs/docs/), which has similar convention but more extensive API.

I do like the structure() which potentially could be used to validate inputs. But how to specify that additional properties are allowed (or denied). Also in many cases if structure doesn't match it's useful to have more detailed feedback what failed, than just true/false.

[wookieb]

Thanks @jpospychala for your feedback!

I've never heard about Ramda but i'll definitely look at it.

But how to specify that additional properties are allowed (or denied).

Well, it's possible but not natively supported for very simple reason: Predicates is not for validation of the input from the user. For validation purposes I highly recommend https://github.com/hapijs/joi

Also in many cases if structure doesn't match it's useful to have more detailed feedback what failed, than just true/false.

That's right but that wouldn't by a predicate anymore (a function that returns only true or false) and breaks the design rule https://github.com/wookieb/predicates/blob/master/docs/design.md#user-content-defined-and-generated-predicates-will-not-throw-any-errors

Please don't get me wrong that i'm lazy or something. Predicates is not for "everything" and doesn't want to be.

I've added a note for structure and provided more examples

[singles]

I really like this library - docs are fine (besides one thing mentioned below), API is ok (besides one thing mentioned below), and what I like about it is order of arguments. 👍

Two suggestions though:

1. Docs for is.regexp should note, that it works for new RegExp too:

console.log( is.regexp( /abc/ ) ); // true
console.log( is.regexp( new RegExp("abc") ) ); // true too

Because currently one might think that it works only for inline regexps.

1. I have doubts about is.object and its behavior.

javascript
var is = require("predicates");

console.log( is.object( {} ) ); // true
console.log( is.object( [] ) ); // true <- shouldn't be false?
console.log( is.object( function() {} ) ); // true <- shouldn't be false?

console.log( is.array( {} ) ); // false
console.log( is.array( [] ) ); // true

I know that array and function are technically an object. It's matter of semantics I guess. But I guess #4 will solve this. 

PS. I'm thinking, if `is.primitive` would be useful (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures). You can always create such predicate with `is.any(is.string, is.number...)` and so on. 

[wookieb]

Thanks @singles !

Docs for is.regexp should note, that it works for new RegExp too:

Fixed

I have doubts about is.object and its behavior.

I've compared my implementation with other libraries

• Underscore has the method isObject that works the same as mine
• Lo-dash has the method isObject that works the same as mine and isPlainObject that works like you've said.
• jQuery has inPlainObject that works the same as isPlainObject from lo-dash
• Angular.js is different. Angular's isObject works like isPlainObject

Predicates works like the majority (underscore, lo-dash, jquery) that's why i've decided to implement it that way.

I'll describe it better along with implementation of #4

PS. I'm thinking, if is.primitive would be useful

Good suggestion! Issue created #12

[Offirmo]

Congrats on achieving 100% coverage, full tests and generated doc !

About the API, chai can be a great inspiration http://chaijs.com/api/bdd/

Chai has "language chain" that I would love in predicates :

is.string.and.is.not.empty

rather than current :

is.all( is.string, is.not(is.empty) )

For length testing, such predicates would be useful : isBiggerThan(2).and.is.smallerThan(80)

Also you state that "predicates is not for validating input". Isn't it a shame when you already provide 90% functionality ? If predicates could set readable flags on what went wrong, we could alert the user of what he's getting wrong.

[colindresj]

Agree with most of what's been said around the practicality and thoughtfulness put into the api. One thing that seems odd to me is that the overall exporting and aliasing of methods occurs outside of the src directory. It my opinion, method names are part of the library and should be included in the source, as should the object that is ultimately exported.

I think there's a lot of benefit in having an index.js file that looks like:

module.exports = require('./src/predicates');

This allows you to contain constants, config, aliasing, etc. inside of the source directory, and exposing the library in a succinct manner. Of course, there's nothing wrong with how the files are currently structured, just thought I would offer my feedback on what looks to be a great new utility library.

[wookieb]

Thank you for your comments!

@Offirmo That's a good idea. Issue created #18

@colindresj
I understand your point and it has one advantage. It would make a browser build a bit lighter (less exports, requires etc). Current minified and gzipped build weights only 3kB so I don't think it's worth the effort at the moment.

Current approach has one important benefit for projects that use commonjs. You can take only necessary functions, not the whole library.

var isString = require('predicates/src/string');
var isStructure = require('predicates/src/structure');

Repeating something like this many times would be very annoying but you can create your own predicates module with list of functions that you need.

// custom/predicates/set.js
exports.string = require('predicates/src/string');
exports.structure = require('predicates/src/structure');

// in project
var is = require('./custom/predicates/set');

is.string('test'); // true

This allows you to contain constants, config

It's possible to have them right now as well :)

Summing it up. I'll remember about your comment and will change the files structure whenever necessary :)