-
Notifications
You must be signed in to change notification settings - Fork 11
.map fn #98
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
Conversation
Not sure about this one yet, I'd say let's get #83 in first then we can use this one to potentially fill in any left over gaps. |
commit: |
@aryaemami59 I keep forgetting this is still a draft. Not a particularly exciting feature but v small implementation cost and somewhat useful so I'd like to get it in. Let me know if you have any thoughts on the code. |
Co-authored-by: Arya Emami <aryaemami59@yahoo.com>
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.
Still not too sure about the name tbh, and we'll add more docs and examples later to cover some of the niche use cases. Other than all looks good to me.
@aryaemami59 another potential helper that occurred to me might be useful. I'm not totally convinced it's worth it, but thought I'd open a draft PR in case you had thoughts. Given
.toBeCallableWith
doesn't work well for generic functions, it's a catch-all way to say "I am allowed to do this with my object" and make assertions on the result, without actually calling the function or performing side-effects, etc.:But the assertion could just as easily (maybe more easily) be written as:
Which also doesn't actually call
capitalize
at runtime.Advantages of
.map
:capitalize
rather than an inline callback.expectTypeOf<X>()
as well asexpectTypeOf(x)
It could also sub in for how we do
.toBeCallableWith
in #83 too: