Just an FYI, you can do this in userland. Just do something like this before your tests,

ShallowWrapper.prototype.childrenAt = function(filter, selector) {
  return this.children(selector).at(filter);
}

tests(wrapper.childrenAt(0)).toBeDefined();

@blainekasten totally... But I believe the idea is to provide as many useful methods as possible internally in the library...

I don't think extending the library on the fly would be the best approach.

Also adding this code or importing it in all my test files wouldn't scale very well...

But thanks for the snippet.

My only concern is that we are creating meaning for an integer in the same argument slot that a selector already is. This doesn't have any issues right now, but if we ever wanted to have a number mean something as a selector, we would not be able to do this.

Using a number as a selector may seem like a strange idea, but it's actually something I've considered for better utility with React Native. React Native produces numbers for the output of StyleSheet.create(), which more or less could act as identifiers in the same way that CSS class names are identifiers for react web.

I'm not in disagreement about the utility of this pattern, though.

An alternative might be to have a new method, called .childAt(number) that does this, without overloading the .children() method.

Thoughts?

childAt sounds good to me, and is a bit more obvious to me that it's doing "at", and returning one thing, then .children(n)

@mauriciosoares would you like to update your PR to use .childAt instead?

cool, I think that childAt(x) may be something less confusing than children(x). Also won't overload the .children method.

I'll update this PR asap.

We could also work on implementing the :first selector and it's siblings.

hey @lelandrichardson and @ljharb I've updated my PR...

Would you mind to take a look? most importantly in the docs? :)

@blainekasten before we go implementing pseudo-selectors, I'd like to investigate how difficult it would be to bring in https://github.com/jquense/bill in a non-breaking fashion.

It would be nice to have the CSS selection bits of enzyme outside of the project. Additionally having a registerPseudo API would be pretty cool.

@mauriciosoares made a couple of comments. It also looks like you are missing the ShallowWrapper implementation and tests.

You're correct. missed that hahaha.

I'll update the code and docs and let you know.

tks

@lelandrichardson I have updated this PR, would you care to take a look? :)

@mauriciosoares looks great. Can you rebase and squash this into one commit for me? That'd be perfect!

@lelandrichardson should I squash the "master merge commit" into mine as well?

@mauriciosoares we prefer the rebase workflow.... if you could do an interactive rebase and remove the merge commit, then rebase from upstream, we should end up with a single commit on top of current upstream/master. Make sense?

@lelandrichardson sorry for the mess...

I believe that now this is what you expected. (I've never used interactive rebase before 😄)

@mauriciosoares perfect! Thanks for doing that. This all looks good - merging.

@lelandrichardson 👍

@lelandrichardson feel free to ping me on the https://github.com/jquense/bill repo with any question you might have. We built it for teaspoon, our enzyme-esque testing lib, so I think there's probably a lot of overlap of needs, and more then happy to collaborate to have it cover more use cases. I had also mentioned this briefly with @ljharb on IRC a while back.