-
Notifications
You must be signed in to change notification settings - Fork 939
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
[InfoWindow] React Portals: Invariant Violation Target container is not a DOM element. #696
Comments
dzuncoi
added a commit
to dzuncoi/react-google-maps
that referenced
this issue
Nov 17, 2017
`6a61f2c` updated `InfoWindow` to support React@^16. Unfortunately, prior to this commit, when re-rendering is triggered from the parent (e.g. due to a state change) without requiring re-mounting, the following error is returned: Invariant Violation Target container is not a DOM element The above error was caused by `this.containerElement` being set to undefined after the component mounts. Consequently, when `render()` is called again, it would fail. If we are always re-mounting the `InfoWindow` component, the aforementioned error will not occur. For example: ``` <Marker position={{ lat: -34.397, lng: 150.644 }}> {showInfoWindow ? (<InfoWindow> <div>Hello World!</div> </InfoWindow>) : null} </Marker> ``` The above code will result in `InfoWindow` re-mounting when re-rendering (e.g. when `showInfoWindow` changes from given props or from the state). ``` <Marker position={{ lat: -34.397, lng: 150.644 }}> <InfoWindow> <div>Hello World!</div> </InfoWindow> </Marker> ``` The above code will throw an error if the encapsulating `render()` method is called multiple times. Again, it is because we are not re-mounting, and because `render()` is not idempotent in the sense that the container element reference is removed after use (or rather, mount). --- Closes tomchentw#696
I have a PR opened for this @tomchentw. If you can have a quick look, that'd be great. |
I've tested @MrSaints pull request and it seems to work fine. However, when adding several markers and infowindows coming from a websocket continuous stream, rendering performance drops dramatically and the component hangs for a while. |
Released v9.2.3 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are encountering issues with using
InfoWindow
in tandem withMarker
. I believe it is related to 6a61f2c. I've tracked the error on development, and production. I'll try to create a small, replicable example.The text was updated successfully, but these errors were encountered: