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

Implement iterable assertion #1592

Merged
merged 4 commits into from
Feb 11, 2024

Conversation

koddsson
Copy link
Member

Pulled this out of #1583 so that these PRs make more logical sense.

This PR implemensts a iterable/isIterable assertion that checks a given object for Symbol.iterator but notably excludes string which does have Symbol.iterator but we don't consider to be "iterable".

@koddsson koddsson marked this pull request as ready for review January 28, 2024 16:06
@koddsson koddsson requested a review from a team as a code owner January 28, 2024 16:06
Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

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

I’m curious why explicitly disallow string for this check?

@koddsson
Copy link
Member Author

I’m curious why explicitly disallow string for this check?

You know, I don't remember why I put that in there. I have a vague memory of the sameMembers test needing this but looking at this in isolations makes me think that's probably a oversight.

43081j
43081j previously approved these changes Jan 28, 2024
Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

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

Is this bit meant to be part of this PR?

@koddsson
Copy link
Member Author

Is this bit meant to be part of this PR?

Not sure if GitHub is glitching but I can't see what this is referring to. I assume it's the isSubsetOf changes in which case, it shouldn't have been included and I've removed those changes. Thanks :)

keithamus
keithamus previously approved these changes Jan 29, 2024
Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

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

I think this is good but I am still a little uneasy about overloading .an() too much.

@43081j
Copy link
Contributor

43081j commented Jan 29, 2024

I think this is good but I am still a little uneasy about overloading .an() too much.

curious, do you prefer .is.iterable then? just so we're all on the same page for other changes in future

im guessing you're unsure of leaning heavily on an for many things, since over time chai would mostly be that one chain

@keithamus
Copy link
Member

I'd prefer each assertion (especially core assertions) to map to something that a user can reproduce with a single expression. It makes it far easier for us to document, and for users to internalise. If they know .an() is just Chai's shorthand for [Symbol.toStringTag] = then that's an easier way to think about it than having a mental lookup table to some alternative logic.

@43081j
Copy link
Contributor

43081j commented Jan 29, 2024

makes sense to me 👍

thanks for the explanation, i do agree

@koddsson
Copy link
Member Author

I think this is good but I am still a little uneasy about overloading .an() too much.

I'm happy to change this. I'd rather nip this in the bud now than trying to untangle it later.

Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

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

Great stuff

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.

3 participants