Skip to content
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

Shadow DOM compatibility #1529

Merged
merged 3 commits into from May 27, 2021
Merged

Shadow DOM compatibility #1529

merged 3 commits into from May 27, 2021

Conversation

lolmaus
Copy link
Contributor

@lolmaus lolmaus commented May 26, 2021

This PR avoids looking up elements via document and id, because such method is unable to pass through the Shadow DOM border.

Instead, it uses https://github.com/lifeart/ember-ref-bucket by @lifeart to reference elements directly.

@lolmaus lolmaus requested a review from simonihmig May 26, 2021 10:43
@lolmaus
Copy link
Contributor Author

lolmaus commented May 26, 2021

Tests are failing in Canary, but those seem to be related to new deprecations.

Should I attempt fixing them in this PR?

@jelhan
Copy link
Contributor

jelhan commented May 26, 2021

Tests are failing in Canary, but those seem to be related to new deprecations.

Should I attempt fixing them in this PR?

Failing tests in beta and canary are a known issue. You can just ignore them unless they are failing in a different way than on current master. See here for details: #1466 (comment)

Copy link
Contributor

@jelhan jelhan left a comment

Choose a reason for hiding this comment

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

Thanks a lot for working on Shadow DOM compatibility. Looks good to me overall. But I haven't much experience with ember-ref-bucket. Would need to look more in detail into it (especially related to autotracking). But maybe @simonihmig can pick it up before. 😸

Comment on lines 80 to 82
console.log('dom', dom);
let destinationElement = findElementById(dom, id) || findElemementByIdInShadowDom(context, id);
// AFJLAJLSFJ AFJ LJ
Copy link
Contributor

Choose a reason for hiding this comment

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

console.log() and the comment looks like left-over from debugging.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed.

addon/utils/dom.js Show resolved Hide resolved
addon/components/bs-modal.js Show resolved Hide resolved
addon/utils/dom.js Outdated Show resolved Hide resolved
addon/utils/dom.js Outdated Show resolved Hide resolved

export function findElemementByIdInShadowDom(context, id) {
const owner = getOwner(context);
return owner.rootElement.querySelector && owner.rootElement.querySelector(`[id="${id}"]`);
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we have to guard against rootElement potentially being a selector string? We discussed this in chat, and I believe that was our conclusion, wasn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Initially yes, but then we stubmled randomly upon owner.rootElement being a string.

So I decided to keep this tiny guard. Does not hurt.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, ok. I misunderstood the code, should have look at it for a second longer 🤦‍♂️
So I was basically "complaining" about that not being guarded, as I was expecting some typeof owner.rootElement like check, but I see it is effectively guarded. You could refactor this to use optional chaining though...

Suggested change
return owner.rootElement.querySelector && owner.rootElement.querySelector(`[id="${id}"]`);
return owner.rootElement.querySelector?.(`[id="${id}"]`);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is optional chaining transpiled correctly? I've only used it with TypeScript so far.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, recent enough versions of ember-cli-babel support it ootb. We use that here frequently!

@lolmaus lolmaus marked this pull request as ready for review May 26, 2021 17:52
Copy link
Contributor

@simonihmig simonihmig left a comment

Choose a reason for hiding this comment

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

LGTM now! 👍

@simonihmig
Copy link
Contributor

FWIW it seems the {{hash}} helper deprecation now found it's way also into ember-release, so that is now also causing failed CI jobs (unrelated to this PR). I prepared a fix upstream at josemarluedke/ember-focus-trap#35. @jelhan fyi

@simonihmig simonihmig merged commit 26ba306 into master May 27, 2021
@simonihmig simonihmig deleted the shadow-dom branch May 27, 2021 06:59
@lolmaus
Copy link
Contributor Author

lolmaus commented May 27, 2021

the {{hash}} helper deprecation

{{hash}} is deprecated?..

@simonihmig
Copy link
Contributor

simonihmig commented May 27, 2021

No, not at all. But setting properties on {{hash}} outside of the template. Like you pass it to a component @model={{hash foo=true}}, and the component does this.args.model.bar=true;. This raises now a deprecation. See:

@jelhan
Copy link
Contributor

jelhan commented May 27, 2021

the {{hash}} helper deprecation

{{hash}} is deprecated?..

Not the {{hash}} helper itself but mutating the value returned by it:

You set the 'initialFocus' property on a {{hash}} object. Setting properties on objects generated by {{hash}} is deprecated. Please update to use an object created with a tracked property or getter, or with a custom helper.

It doesn't seem to be listed yet on https://deprecations.emberjs.com/v3.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants