-
-
Notifications
You must be signed in to change notification settings - Fork 698
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
Make 'empty' throw on non-string primitives and functions #812
Conversation
this.assert( | ||
Object.keys(Object(obj)).length === 0 | ||
0 === itemsCount |
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.
Is there any ESLint config we can add to the project? This will greatly improve contribution/review experience: yoda comparisons and comma-first are not quite popular and it would be awesome to automate codestyle checks.
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.
@shvaikalesh Yes, we thought about that too, we already discussed that here and we came to the conclusion that by moving all our code to separate repos with their own linting rules would be better, however, if you disagree you're welcome to share your thoughts with us 😄 .
case 'function': | ||
throw new TypeError('.empty() was passed a function'); | ||
default: | ||
if (val !== Object(val)) { |
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.
Other option is to add case
clause for other primitives' types.
case 'string': | ||
itemsCount = val.length; | ||
break; | ||
case 'function': |
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.
This should handle generators too (because of recent updates to type-detect
) and async
function in the future.
@shvaikalesh Thank you for your continued work on this! Implementation looks fine to me. However, I think we should update the jsdoc to clarify that only non-function objects are allowed. Other thoughts:
|
@meeber I have updated jsdoc. Throwing on weak collections is nice idea, absolutely agree. Totally interested in adding One more thought: it seems like tests for most assertions are repeated for every interface they are available for. Would be great to have only one test suite for each assertion. |
@shvaikalesh Yeah adding tests is painful right now due to the multiple interfaces. There was a discussion about this somewhere but I can't find it. Anyway, the long term idea as we move into a modular system as described in #457 is to only have to write tests once for each assertion. But we're not quite there yet. Regarding this PR: LGTM! |
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.
Hello @shvaikalesh,
First of all thank you so much for all the effort you've been putting into this issue with .empty since #763.
I just add a comment about the messages inside TypeError
itemsCount = val.length; | ||
break; | ||
case 'function': | ||
throw new TypeError('.empty() was passed a function'); |
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.
What about replacing .empty()
with .empty
since it is a property assertion?
throw new TypeError('.empty() was passed a function'); | ||
default: | ||
if (val !== Object(val)) { | ||
throw new TypeError('.empty() was passed non-string primitive'); |
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.
What about replacing .empty()
with .empty
since it is a property assertion?
I'll just leave my LGTM in case you guys think that my comment is just nitpicking. Agreed with you and @meeber about P.S. This just made me realize that we might consider throwing |
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.
Thanks for your work @shvaikalesh, this is looking great, however, as @vieiralucas said maybe we could just swap .empty()
for .empty
in the error messages.
After that I will be very happy to merge this in.
Thanks! 😄
case 'function': | ||
throw new TypeError('.empty() was passed a function'); | ||
default: | ||
if (val !== Object(val)) { |
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.
Great use of Object()
. 😍
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.
That blew my mind to!
this.assert( | ||
Object.keys(Object(obj)).length === 0 | ||
0 === itemsCount |
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.
@shvaikalesh Yes, we thought about that too, we already discussed that here and we came to the conclusion that by moving all our code to separate repos with their own linting rules would be better, however, if you disagree you're welcome to share your thoughts with us 😄 .
itemsCount = val.length; | ||
break; | ||
case 'function': | ||
throw new TypeError('.empty() was passed a function'); |
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.
As @vieiralucas said, I think .empty()
should be changed to .empty
since it's a property assertion.
@lucasfcosta @vieiralucas UH OH THE LUCAS SYNDICATE IS IN FULL FORCE TODAY. Just a reminder to whoever ends up merging: Squash and merge! :D |
@meeber hahaha yes, thanks for remembering us to do that 😄 |
I have removed |
default: | ||
if (val !== Object(val)) { | ||
throw new TypeError('.empty() was passed non-string primitive'); | ||
throw new TypeError('.empty was passed non-string primitive ' + String(val)); |
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.
We need String
here because it special-cases symbols. Otherwise, they throw on ToString
.
EDIT: oops, that fails in Node 0.12 because of partial implementation. Let's do toString
.
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.
You could use the inspect utility.
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 think I'm okay without it since the error message is pretty self-explanatory.
Also, if you want to add that anyway, I wouldn't mind, just try using _.type()
, since it may be more accurate.
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.
Ah, I just noticed you want to print the value of what was passed, not it's type.
Then @vieiralucas is right, the inspect
utility would be ideal.
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.
_.type()
is better IMO
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.
okay, so, if we're going to use type
we need to rephrase the error message to something like:
.empty was passed non-string primitive of type ' + _.type(val)
PS.: Sorry for all this mess in the comments @shvaikalesh 😆
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.
Okay, calm down everyone hahahha:
THUMBS UP IF YOU VOTE FOR TYPE
AND HEART THIS COMMENT IF YOU VOTE FOR INSPECT
.
If we three vote there's no way this is going to be a tie.
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.
Okay, let's do type
then. Or not. Huh, need to refresh the page to see new comments, like in good ol' times.
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 am for inspect
because you can definitely tell primitive type by the value, but not otherwise. May save console.log
typing for someone.
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.
Okay, so we're going for inspect
.
Also, since inspect
also adds delimiters which denote the type of the value (like []
for arrays and ''
for strings), it is more complete.
Thanks for this @shvaikalesh!
LGTM!
LGTM again because something went wrong with approvals/lgtm |
Thanks for the merge, awesome contribution experience ❤️ . |
Squashed and merged! |
Thank you so much @shvaikalesh, looking forward for your next contributions. 😄 |
No more caffeine for The Lucas Syndicate. |
Follow-up of #763.