If we agree that this is an acceptable change to the RST spec I can include the changes to the adapters and spec alongside the work I'm doing integrating a CSS parser with the RST traversal stuff.

Would adding a parent pointer preclude the need for sibling iterators? It might be less complex then enforcing the idea of a finite and non-repeating list of ordered siblings.

In what situations could an RST represent a set of child nodes that aren't finite, unique and ordered? I think even if an element was repeated it would be represented by a unique node, but I'm not sure.

Having just a parent pointer would be a find compromise though. It would still require a linear search for sibling selectors but that's probably not too costly in most cases.

All three seem reasonable fwiw (nextSibling, prevSibling, parent) but it'd be nice to minimize the API surface :-)

While working on #1086 I found that the only time I needed to get the parent was to get a sibling, and I never had to match a previous sibling since CSS selectors only match following siblings.

So I think we could get away with just nextSibling unless there are other APIs that would benefit from prevSibling or parent?

If we have next, I think we need prev. I'm less concerned about parent tho, since theoretically you got to a node from the parent.

Without a parent link how do you implement https://github.com/airbnb/enzyme/blob/master/docs/api/ShallowWrapper/parent.md ? By starting from the root and following children until you get to the current node?

@nfcampos that's exactly how it does it: https://github.com/airbnb/enzyme/blob/master/packages/enzyme/src/RSTTraversal.js#L74-L76

I was only thinking about it in the context of the selector API, but a parent pointer would definitely be helpful here. Since it's an internal API used only by adapters, maybe it's OK to increase the API surface and add all three? prevSibling is the least useful, but it does make sense to include it if we have nextSibling (which is really useful).

Sounds like there's use cases for all three then.

@lelandrichardson, thoughts?

@aweary i worry about adding these types of things when JS doesn't have weak references. I think it also makes actually building an RST much more complicated. Since this is just traversal stuff, It'd be nice if any logic around prev/next sibling etc was contained inside enzyme. If we wanted to transform an RST into a structure that had these pointers, that might make sense... but i also am not sure i'm convinced that this is a good idea.