Issue:
Testing QSelect and other portal dependent components is heavy and time consuming. By portal dependent I mean the components that actually trigger portal based components to appear e.g. Menu, Dialog.
The biggest problem is that portal based components like Menu do not know know who called them and this causes the issue when testing components specifically or during E2E tests. Couple of different menu or dialogs can be open at the same time and withinSelectMenu command might bot be able to handle this scenario.
Solution:
When QSelect triggers mount for QMenu or QDialog, a specific attribute that should be put onto the instantiated portal based component to be able to refer to the caller. In this case custom commands like "withinSelectMenu" can become chainable or can accept a selector be able to query the menu trigerred by selector
Cypress.Commands.add('withinSelectElement', { prevSubject: 'optional' }, (subject, callback, selector) => {
if (subject && !selector) {
/**
Assume all menus created by use of QSelect have data-caller="1"
*/
selector = ".q-menu" + "[data-caller=" + subject.attr('id') + "]"
}
cy.root().closest('html').get(selector).within(callback)
})
cy.dataCy('dropdown-persons').withinSelectElement(() => {})
There is a way however to circumvent it now, it is by passing selector to "popupContentClass" in QSelect element and explicitly querying this element, however I beleive that is not the best solution
IMPORTANT NOTE
This requires updating the QSelect element, and is not only matter of updating this package.
Issue: Testing QSelect and other portal dependent components is heavy and time consuming. By portal dependent I mean the components that actually trigger portal based components to appear e.g. Menu, Dialog.
The biggest problem is that portal based components like Menu do not know know who called them and this causes the issue when testing components specifically or during E2E tests. Couple of different menu or dialogs can be open at the same time and withinSelectMenu command might bot be able to handle this scenario.
Solution: When QSelect triggers mount for QMenu or QDialog, a specific attribute that should be put onto the instantiated portal based component to be able to refer to the caller. In this case custom commands like "withinSelectMenu" can become chainable or can accept a selector be able to query the menu trigerred by selector
There is a way however to circumvent it now, it is by passing selector to "popupContentClass" in QSelect element and explicitly querying this element, however I beleive that is not the best solution
IMPORTANT NOTE
This requires updating the QSelect element, and is not only matter of updating this package.