Hello,
I’m wondering whether @Quentin or somebody from the team could help me with my issue.
I’m trying to embed the following code into my WeWeb HTML Embed Widget, but it is not working, seems like Google Maps API script is ignored. I need to load it like this, because I’m using a custom library, Drawings API library.
https://maps.googleapis.com/maps/api/js?key=[API Key is redacted]&callback=initMap&libraries=drawing&v=weekly
Am I doing something wrong? Or is there issue on your side?
Seems to me like all the other scripts get loaded but the scripts from Maps.
Thanks a lot 
How are you loading the google maps library? Are you putting a script tag into the header using the custom code functionality? Using the weweb-embed tool?
I tried both head and HTML embed, but with no success, jQuery embed I tried for example worked, but this one does not. Even though on Webflow or localhost in an HTML file works like a charm.
are you using weweb’s map element and your own script in the same page?
Google maps can’t be loaded twice in the page. You should have an error in the dev console complaining about that.
If you want import the library by yourself then you can’t use weweb’s component, or you need to have the conditional display of the map set to false (using a variable), then load google maps with the js api loader, then set conditional display of the maps to true to finally show the map.
Be sure to have “conditional display” to false on initial page load otherwise the map element will load the library before you can
1 Like
Hey @dorilama I’m loading only one instance, but it is not working. I’m following this example.
If you also have weweb’s map element in the page then you are loading it twice: the element is loading it and you are loading it.
Check the dev console to see what’s happening.
I do not have the weweb’s map element in the page. I had that error before, and I removed it. In the console it doesn’t say anything. Otherwise I’d be debugging it rn 
I’ll try to make this all over from scratch and I’ll get back to you.
the library does not initiate the map by itself. from your post it looks like you are just loading the library.
I’m having all the code there, I’m successfully loading the map on two different Platforms.
https://roberts-ultra-awesome-site-8ff109.webflow.io/maps
Webflow for example works without any pains of embedding scripts through anything else, just a plain HTML widget.
DId you fix your problem? Map came up for me in the linked site
Hey @raydeck No, the linked site is a Webflow static site, I haven’t managed to replicate this in WeWeb yet unfortunately.
an html element in weweb is not server side html, it’s rendered in the client hand has its own logic to load and execute the scripts. Trying to load the map library with a defer attribute and using the callback parameter to trigger a global function is not going to work because the timing of the execution is not what you expect.
Your flow should be:
- load the map library and wait for it to be fully loaded. Either add the script yourself and the logic to wait for it to load or use the script I linked, that will do everything for you automatically with an async function that you can await.
- once the library is loaded trigger a workflow with a js action where you put your code to create the map. If you are targeting an element added in weweb’s html element you need to keep in mind that it may not be rendered in the page yet and you need an observer to wait for it.
what you need is very doable with js actions and html element, it’s just a little more complicated than you expect and it is also a case where making the same thing in a custom element is much more better because you have full control.
1 Like
I took a run at implementing this myself in a State Change speedrun video - maybe it helps you with where you are getting stuck?: Link Google Maps to Weweb in 15 Minutes - YouTube
2 Likes
I got stuck exactly at the timeout part, I’ve not thought about delaying it till the div loads! You’re cool man Is this 100% bulletproof though? is the div gonna load always withing 500ms? How about the users with slow connections for example? I’m loving how u’r solving these problems on video though! Definitely subscribing!
1 Like
You could use a recursive function to wait for the element to be live on screen, then fire off the rest of the code.
I ran into this issue last week with color pickers.
2 Likes
a delay is good enough but it will randomly fail because the timing is different every time. Sure, you can increase it enough to make it fail very rarely, but you will penalize the speed for every user.
a recursive timeout is a good method to accidentally create an infinite loop that will block the page.
When you want more control and consistency you should go for a mutation observer whis is the native way of getting notified as soon as an element gets rendered in the page without workarounds.
1 Like
Mutation observers weren’t playing nicely for me, actually. After you mentioned that previously I tried it. But it wasn’t seeing a div even though it was visually on the loaded screen until I switched screens and came back.
Seemed like the element was maybe visible before the mutation observer was live and so the observer had nothing to observe?
That said, if I could make it work right it would be my preferred method.
the pattern is:
- search for the element
- if is there go with your logic
- if is not there start the observer and go with your logic when it’s time
it’s easier if your logic is wrapped inside a function
some libraries abstract this logic in a very nice way
1 Like
Ease in, and prioritize your momentum and joy in the process. A timeout is a fast-but-imperfect solution to the problem. I use them all the time because they work well as a starting point. Then you can look at replacing the timeout with a more sophisticated option as you get closer to shipping and you see which parts of your system are more and less “bullet-proof,” and how they interact so that your solution is addressing the manner in which they fail.
@dorilama lays out a great general pattern - it’s a best practice. There are intermediary steps you can take depending on how much the edge cases effect you and what shows in your testing.
As a mental model, look to move toward best practices as you grow in your skill rather than making it a blocker for yourself at the beginning.
1 Like
I agree with doing it in steps.
If you are learning it’s good that you try and enjoy the learning process.
When you find the random bug in your path just remember to check if it may be connected to the workaround. Maybe leave a comment in the code for your future self, to save time when you debug.
2 Likes
