-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(deps): Remove check-types in favor of lodash #104
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,12 +5,13 @@ | |
note: you may inject your own variables when calling the constructor | ||
**/ | ||
|
||
var check = require('check-types'), | ||
Variable = require('./Variable'); | ||
const _ = require('lodash'); | ||
|
||
const Variable = require('./Variable'); | ||
|
||
function VariableStore( vars ){ | ||
this._vars = {}; | ||
if( check.assigned( vars ) ){ | ||
if( !_.isEmpty( vars ) ){ | ||
this.set( vars ); | ||
} | ||
} | ||
|
@@ -31,17 +32,19 @@ function VariableStore( vars ){ | |
vs.var('foo').set('bar'); | ||
**/ | ||
VariableStore.prototype.var = function( key, val ){ | ||
if( !check.nonEmptyString( key ) ){ | ||
if( _.isEmpty( key ) || !_.isString( key) ) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't believe this is correct, my understanding of You might have to write it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree that reading through the docs, it sounds like it shouldn't work, unless the definition of a "collection" is anything that has a |
||
throw new Error( 'invalid query variable, key must be valid string' ); | ||
} | ||
// init variable | ||
if( !this._vars.hasOwnProperty( key ) ){ | ||
this._vars[ key ] = new Variable(); | ||
} | ||
// setter | ||
if( check.assigned( val ) ){ | ||
|
||
// set value if val parameter passed | ||
if (val !== undefined) { | ||
this._vars[ key ].set( val ); | ||
} | ||
|
||
// getter | ||
return this._vars[ key ]; | ||
}; | ||
|
@@ -50,7 +53,7 @@ VariableStore.prototype.var = function( key, val ){ | |
check if a key has been set (has a value) | ||
**/ | ||
VariableStore.prototype.isset = function( key ){ | ||
if( !check.nonEmptyString( key ) ){ | ||
if( _.isEmpty( key ) || !_.isString( key) ) { | ||
throw new Error( 'invalid key, must be valid string' ); | ||
} | ||
// key not set | ||
|
@@ -65,7 +68,7 @@ VariableStore.prototype.isset = function( key ){ | |
delete a variable by key | ||
**/ | ||
VariableStore.prototype.unset = function( key ){ | ||
if( !check.nonEmptyString( key ) ){ | ||
if( _.isEmpty( key ) || !_.isString( key) ) { | ||
throw new Error( 'invalid key, must be valid string' ); | ||
} | ||
// key not set | ||
|
@@ -81,7 +84,7 @@ VariableStore.prototype.unset = function( key ){ | |
import variables from a plain-old-javascript-object | ||
**/ | ||
VariableStore.prototype.set = function( pojo ){ | ||
if( !check.object( pojo ) ){ | ||
if( !_.isPlainObject( pojo ) ){ | ||
throw new Error( 'invalid object' ); | ||
} | ||
for( var attr in pojo ){ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to check for the nil number value
NaN
here also?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I was trying to preserve the existing behavior as much and as simply as possible, but
NaN
is definitely in the same boat asnull
andundefined
as generally not useful.On the other hand, and especially considering #13, which could be fixed by removing the restriction on storing an empty string, its kinda worth considering if we should filter out any values at all at this point.
null
andundefined
at least would both cleanly serialize (to nothing) in JSON, so why not allow that if we allow so much else?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to merge this as is but I'm definitely up for re-visiting allowed/disallowed values. I think we should allow
''
to fix #13, figure out if we can stop allowing objects (which just sounds like a painful way to introduce weird behavior), and revisitnull
/undefined
/NaN
etc.