-
Notifications
You must be signed in to change notification settings - Fork 112
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
feat: add hover events and anchor points to advanced markers #472
feat: add hover events and anchor points to advanced markers #472
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.
Excellent, thanks a lot!
I think there's just two things missing here: updated documentation and some more explanations about the DOM structure being built for the marker.
What do you think, do we need to be worried that the added dom-element will cause backwards compatibility issues?
@@ -58,7 +58,15 @@ export const Pin = (props: PropsWithChildren<PinProps>) => { | |||
} | |||
|
|||
// Set content of Advanced Marker View to the Pin View element | |||
advancedMarker.content = pinElement.element; | |||
const markerContent = advancedMarker.content?.firstChild; |
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 could use some more explanation with this, isn't the cleanup below something that the react portal will take care of? Maybe I'm condifusing the different elements here.
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 fixes an issue that has already been addressed in #428 where the the Pin component would overwrite the styles on an advanced marker by setting the content rather than replace the children.
Below is just a more verbose way of saying ...replaceChildren(pinElement.element);
since that doesn't seem to be supported by our transpile target I think.
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.
very cool, almost there :)
src/components/info-window.tsx
Outdated
if (anchorWidth === 0 && anchorHeight === 0) { | ||
// We can safely typecast here since we control that element and we know that | ||
// it is a div | ||
const anchorDomContent = anchor.content.firstChild as 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 could be risky, I think firstChild
could also be a text- or even a comment-node, using Element.firstElementChild
should be fine here.
src/components/info-window.tsx
Outdated
anchorDomContent?.getBoundingClientRect().width; | ||
|
||
const anchorComputedStyles = getComputedStyle(anchorDomContent); | ||
const transformMatrix = new WebKitCSSMatrix( |
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 sure about the Webkit
prefix, I think it's now called DOMMatrix
.
If I understood this right, we need to compute the offset of the top/center of the marker-content to the current position of the marker. According to the spec, getBoundingClientRect() already have all transforms applied, so we could maybe just take the values from there? Maybe the BCR of our 0x0 anchoring div could be used as reference to get to the actual offset.
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.
Good point :) Yes we can.
can you also have a look at this comment here: #368 (reply in thread)? Is this going to be obsolete with the new implementation? |
Yes, I think that should be resolved with the new implementation |
No description provided.