-
Notifications
You must be signed in to change notification settings - Fork 40
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
More granular query methods with predicate function and/or props #9
Comments
Hi! Thanks for the feedback. The current inconsistent APIs are mostly a result of evolution from the original API and various holes we found via internal use. Every time I added a feature I kept backwards-compatibility with the previous stuff. I'm not entirely sure that all the existing APIs make sense. I like the idea of being able to pass a filter function as well. There's also a semi-hidden At the moment there's 3 different families:
And currently subTree has the This seems a bit muddled - internally the implementation is all just a single tree-walk function which takes a predicate - so any combination of the above is pretty doable. We could just expand all 3 flavours so they support all the variants, but ideally I'd like to trim down a bit. |
Here's some stats from our 3 internal testsuites - I'll ask around the office as well and see what people think. grep -hriEo 'findComponent(like)?|(every)?subTree|findNode' -- test | sort | uniq -c | sort -n
The skew towards |
Thanks, that's good info. I agree that the API could use some refinement. One thing about my use case is that my app has very few |
We've actually been putting in specific classes for our end-to-end selenium tests, and then hooking some unit tests of those, eg |
One thing I've noticed we do a lot is |
We had a chat internally, current thinking is to trim down to
And expand these so they all take a selector as the first argument, and a props object / predicate as the second argument. |
Summary of current plan
|
That sounds great! |
I'm working on writing up notes for a The idea is to change the API to push users towards loose selectors over strict ones. |
A possible approach would be to use the fact that the new API will accept a function as the second argument for the overloading: // match subset of props
tree.subTree('Component', { some: 'prop' });
// match exact props
tree.subTree('Component', sd.exact({exact: 'props'})); This would allow trimming down the top-level selection API to only |
I've posted a draft of introduction and overview docs for what would become the 1.0 API: https://github.com/glenjamin/skin-deep/tree/one-point-oh |
Definitely agree with the change to Have you thought about dropping support for react 0.13 when jumping to v1.0? |
I thought about dropping 0.13, but we've not upgraded at work yet, and the compat layer is quite thin so I'll probably keep it. Might do 0.99 and save 1.0 for when 0.13 drops |
It would be great to be able to do more granular searches by passing a props or function argument to query methods):
On a related note, it would be nice if there was an
everySubTreeLike
method analogous tofindComponentLike
and more "plural" methods to return multiple nodes/components e.g.findNodes
/findComponents(Like)
/whathaveyou.The text was updated successfully, but these errors were encountered: