You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the absence of class is very rare case to test and it can already be handled easily without this library by common react testing practices. So it should be better to treat expected string differently.
As an enumeration of what is absolutely required to be found in a rendered node.
If we include attribute in expected string – we require its presence
If we don't include attribute – we're agnostic about it
Then we don't need to create and support that clunky white and black lists with magic "defaults".
As I already said, If we still do need to query against some attributes in a more explicit form we always can fallback to lower level tools.
I believe this approach is more sane than the current one. You can also make a described one a default behavior with alternatives switched by flags but I tend to think that such global and rigid control is a bad style.
For some nodes you want to be more precise, for others – less precise and this is probably
just impossible to preconfigure through options.
This brings up some great points. I looked through my usages of this library, and I think the above approach makes sense. I'll try implementing the above approach and see if it really works for these use cases.
The text was updated successfully, but these errors were encountered:
As per #1:
This brings up some great points. I looked through my usages of this library, and I think the above approach makes sense. I'll try implementing the above approach and see if it really works for these use cases.
The text was updated successfully, but these errors were encountered: