Skip to content

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

Merged
merged 14 commits into from
Mar 9, 2020

Conversation

mmalerba
Copy link
Contributor

This allows the user to drop in a shadow-piercing version of
querySelectorAll to handle components that use
ViewEncapsulation.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 the main. The e2e test kept loading that instead of the umd, and I wasn't sure how to configure it

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jan 15, 2020
Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

*/

declare module 'kagekiri' {
export function querySelectorAll(selector: string, root: Element);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not also querySelector?

Copy link
Contributor Author

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):
Copy link
Member

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';
Copy link
Member

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

@mmalerba mmalerba force-pushed the shadow branch 2 times, most recently from 7c586c3 to 69ca864 Compare January 17, 2020 00:34
@mmalerba mmalerba force-pushed the shadow branch 4 times, most recently from b664c3b to 7d83aca Compare January 28, 2020 20:16
(selector: string, root: ElementFinder) => root.all(by.js(function(this: any) {
piercingQuerySelectorAll(selector, this);
}));
// TODO: is there some better way to do this?
Copy link
Member

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.

@mmalerba mmalerba marked this pull request as ready for review January 29, 2020 16:51
@mmalerba mmalerba requested a review from a team as a code owner January 29, 2020 16:51
@mmalerba
Copy link
Contributor Author

This is ready for review now. Added unit and e2e tests that demonstrate using a custom queryFn to support shadow DOM components


declare module 'kagekiri' {
export function querySelectorAll(selector: string, root: Element): NodeListOf<Element>;
}
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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 😄

Copy link
Contributor Author

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

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker target: minor This PR is targeted for the next minor release labels Jan 30, 2020
Copy link
Member

@devversion devversion left a 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.

@mmalerba mmalerba removed the action: merge The PR is ready for merge by the caretaker label Jan 31, 2020
@mmalerba mmalerba force-pushed the shadow branch 2 times, most recently from 6e0e525 to 7f52b4d Compare January 31, 2020 20:31
@mmalerba mmalerba added the action: merge The PR is ready for merge by the caretaker label Jan 31, 2020
@jelbourn
Copy link
Member

jelbourn commented Feb 6, 2020

@mmalerba needs rebase

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants