Skip to content
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

Avoid unnecessary inference of stack for label #213

Merged
merged 6 commits into from
Jun 26, 2021

Conversation

hanshsieh
Copy link
Contributor

  • For ow.isValid, it's acutually not necessary to inference the stack for the label because the message won't actually be used.
  • For the check of elements, e.g. ow.object.valuesOfType, ow.array.ofType, ow.map.keysOfType, ow.map.valuesOfType, ow.set.ofType, the inference of the label can also be avoided.
  • The original reason why I want to avoid the inference of label is not because of performance. It was because Error.prototype.stack is not in the standard. And it isn't available in Goja. When ow tries to use callsites to inference the stack, it will cause an error TypeError: Cannot read property 'slice' of undefined or null because of this line. For most cases, users of ow can explicitly specify the label to avoid the inference such as ow(value, 'value', ow.string). However, the cases mentioned above is out of the control of the users.
  • After the change in this PR, the error message is changed for some cases. I'm not sure if it is acceptable. If anyone has a better idea for this problem, feel free to commit to my branch or close my PR and create your own. :)

- For `ow.isValid`, it's acutually not necessary to inference the stack for the label because the message won't actually be used.
- For the check of elements, e.g. `ow.object.valuesOfType`, `ow.array.ofType`, `ow.map.keysOfType`, `ow.map.valuesOfType`, `ow.set.ofType`, the inference of the label can also be avoided.
- The original reason why I want to avoid the inference of label is not because of performance. It was because `Error.prototype.stack` is not in the standard. And it isn't available in [Goja](https://github.com/dop251/goja). When `ow` tries to use `callsites` to inference the stack, it will cause an error `TypeError: Cannot read property 'slice' of undefined or null` because of [this line](https://github.com/sindresorhus/callsites/blob/6dc8cb32082c54c65c0e38672e00162c9362be22/index.js#L6). For most cases, users of `ow` can explicitly specify the label to avoid the inference such as `ow(value, 'value', ow.string)`. However, the cases mentioned above is out of the control of the users.
- After the change in this PR, the error message is changed for some cases. I'm not sure if it is acceptable. If anyone has a better idea for this problem, feel free to commit to my branch or close my PR and create your own. :)
@hanshsieh hanshsieh marked this pull request as ready for review June 5, 2021 14:52
test/map.ts Outdated
@@ -178,11 +178,11 @@ test('map.valuesOfType', t => {

t.throws(() => {
ow(new Map([['unicorn', '🦄']]), ow.map.valuesOfType(ow.number));
}, '(Map) Expected argument to be of type `number` but received type `string`');
}, '(Map) Expected `item` to be of type `number` but received type `string`');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect since we use backticks to indicate variable names or types.

It should ideally be:

Suggested change
}, '(Map) Expected `item` to be of type `number` but received type `string`');
}, '(Map) Expected item 0 to be of type `number` but received type `string`');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. I'll take some time to see how to achieve that.

@hanshsieh
Copy link
Contributor Author

I rolled back some changes and focus on ow.object.ofType only. Please check how it looks now. :)


@hidden
@param source Source collection to test.
@param name The name to call the collection of values, such as "values", "keys".
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs to be a separate assertion. You can just add an optional parameter to of-type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the PR.
After we migrate all usages of ofType to specify the optional name parameter, we can change that to be required.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After we migrate all usages of ofType to specify the optional name parameter, we can change that to be required.

Can you add a code comment about that? So we don't forget.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, updated the comment.

@sindresorhus sindresorhus merged commit 6075739 into sindresorhus:main Jun 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants