Is it possible to query from a previous result of a query?

[maxime1992]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

When I use queryAll, I'd like to extract values to get an array of current values that I can compared to an array of expected values. For example if I've got:

<div data-animal>
  <div data-name>Dog1</div>
  <div data-bark>Woooof1</div>
</div>

<div data-animal>
  This spot is empty
</div>

<div data-animal>
  <div data-name>Dog2</div>
  <div data-bark>Woooof2</div>
</div>

and I want to be able to test the name of every animal.

So I'd write something like:

const animals = spectator.queryAll('[data-animal]')
const currentAnimalsNames = animals.map(animal => {
  // here I don't know how but I'd like to wrap `animal` into a spectator query from within I could search, ex:
  // spectator.queryFrom(animal, 'name')
})

const expectedAnimalsNames = ['Dog1', undefined, 'Dog2']

expect(currentAnimalsNames).toEqual(expectedAnimalsNames);

Expected behavior

Any way of achieving that already?

Should I just write that test in a completely different way?

What is the motivation / use case for changing the behavior?

Being able to query from an element would be helpful and precise.

[dirkluijk]

What about array destructuring combined with toHaveDescendantWithText() matcher?:

const [animal1, , animal3] = spectator.queryAll('[data-animal]')

expect(animal1).toHaveDescendantWithText({ selector: '.data-name', 'Dog1'});
expect(animal3).toHaveDescendantWithText({ selector: '.data-name', 'Dog3'});

or, even simplier, but less accurate:

const [animal1, , animal3] = spectator.queryAll('[data-animal]')

expect(animal1).toHaveText('Dog1');
expect(animal3).toHaveText('Dog3');

But, to answer your question, you could also use:

const [animal1, , animal3] = spectator.queryAll('[data-animal]')

expect(animal1!.querySelector('.data-name')).toHaveExactText('Dog1');
expect(animal3!.querySelector('.data-name')).toHaveExactText('Dog3');

(the non-null assertion ! can be left out if not using strictNullChecks)

[maxime1992]

Thanks @dirkluijk, that'll help.

But I'll also give you another example. If I want to select by component, I can use the syntax spectator.query(MyComponent). Now, imagine I've got 2 of them and I want to be more specific. How can I target one or the other in a simple way?

Something like spectator.query('.first-instance-wrapper').query(MyComponent) would be really helpful I think

[dirkluijk]

I understand. The only way to do this, if that we patch the returned element with a custom query() method, so it will be something like Element & { query: () => ... }. Not sure if that will cause issues.

@NetanelBasal what do you think?

[NetanelBasal]

I think it's a helpful feature that worth a try :)

[NetanelBasal]

The issue is that it will break the code. The code now returns the element. It could be something like spectator.query('.first-instance-wrapper', { chained: true })

[dirkluijk]

The issue is that it will break the code.

Yes, that's what I thought. However, is returning a subtype considered a breaking change?

[ekhmoi]

I think it will break compilation when someone has defined return type for query

const select = spectator.query('#test-onchange-select') as HTMLSelectElement;

Although I don't like it but if query is optional it shouldn't break anything.

[NetanelBasal]

I'm closing this issue for now.

[maxime1992]

Can you explain why?

I think it's a helpful feature that worth a try :)

If there's no issue to track it, it will just be forgotten 🤔