-
Notifications
You must be signed in to change notification settings - Fork 6.8k
feat(cdk/testing): Allow custom querySelectorAll
method
#18178
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
src/cdk/testing/kagekiri.d.ts
Outdated
*/ | ||
|
||
declare module 'kagekiri' { | ||
export function querySelectorAll(selector: string, root: Element); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not also querySelector
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, all the harness stuff runs off just qsa
super(rawRootElement); | ||
} | ||
|
||
/** Creates a `HarnessLoader` rooted at the document root. */ | ||
static loader(): HarnessLoader { | ||
return new ProtractorHarnessEnvironment(protractorElement(by.css('body'))); | ||
static loader(queryFn?: (selector: string, root: ElementFinder) => ElementArrayFinder): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to add a config object rather than passing the query impl directly in case we want to add more options in the future. I think putting it in a config also helps de-emphasize the custom querySelector impl.
@@ -12,6 +12,7 @@ import {MainComponentHarness} from './harnesses/main-component-harness'; | |||
import {SubComponentHarness, SubComponentSpecialHarness} from './harnesses/sub-component-harness'; | |||
import {TestComponentsModule} from './test-components-module'; | |||
import {TestMainComponent} from './test-main-component'; | |||
import {querySelectorAll as piercingQuerySelectorAll} from 'kagekiri'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would a querySelector that cuts through the shadows be a luminousQuerySelectorAll
?
that's a joke
7c586c3
to
69ca864
Compare
b664c3b
to
7d83aca
Compare
(selector: string, root: ElementFinder) => root.all(by.js(function(this: any) { | ||
piercingQuerySelectorAll(selector, this); | ||
})); | ||
// TODO: is there some better way to do this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's the right way to do it that way. Kagekiri can never provide types that always reserve the global kagekiri
namespace. It always depends on whether the UMD bundles have been loaded or not.
I think this boilerplate is reasonable (declaring a const that needs to be named kagekiri
globally). In an ideal world, it would just refer to an official type of kagekiri
for type safety.
It would be also possible to avoid the boilerplate by just passing in a string to by.js
. That is less type-safe, but given that we don't have official kagekiri types anyway, it seems to be unsafe anyway. I still prefer the current way though.
This is ready for review now. Added unit and e2e tests that demonstrate using a custom queryFn to support shadow DOM components |
src/cdk/testing/kagekiri.d.ts
Outdated
|
||
declare module 'kagekiri' { | ||
export function querySelectorAll(selector: string, root: Element): NodeListOf<Element>; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is only used for the tests of cdk/testing
right? Should we make that clear in a comment, or in the file name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we have a file name convention for this, .spec.d.ts? I added a comment though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for a comment. Regarding convention: My concern right now is that this file will end up in the release output since it matches the .ts
glob. IMO it should be just denoted with .spec
so that it automatically is filtered out, and it's obvious (without viewing the file) that it's spec only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean it will get included because the bazel rule globs on *.ts
? I think even renaming it to kagekiri.spec.d.ts
won't fix it, since that won't match the exclude glob *.spec.ts
. Should I rename it and update the bazel globs in this package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right. I think we can manually exclude the file in the exclude
glob, or we change it to .spec.d.ts
and update the glob to handle it. Up to you what way you choose 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I called it .spec.d.ts, we now officially have a precedent if we ever need to do this again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me! I replied on the kagekiri.d.ts
file again, but I think in any case, this should be good to go.
6e0e525
to
7f52b4d
Compare
@mmalerba needs rebase |
This allows the user to drop in a shadow-piercing version of `querySelectorAll` to handle components that use `ViewEncapsulation.ShadowDom`
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This allows the user to drop in a shadow-piercing version of
querySelectorAll
to handle components that useViewEncapsulation.ShadowDom
I've gotten a unit test working that uses kagekiri to demonstrate working with components that use
ViewEncapsulation.ShadowDom
.It should be possible to get an e2e test working using the same library, but I had some difficulty getting it set up. The librariy's
package.json
specifies the common js module as themain
. The e2e test kept loading that instead of the umd, and I wasn't sure how to configure it