HTML Elements and Sending Data — Multiple Markers on Google Maps with Wix Velo

Adventures with Wix Velo

HTML Elements and Sending Data — Multiple Markers on Google Maps with Wix Velo

Welcome back to my series on displaying multiple locations on Google Maps with Wix Velo. I really appreciate you taking some time to have a look at my tutorial, and I’d love to hear from you in the comments below.

Our Goal For the Series

Our goal in this series is to build a website which fully integrates the display of multiple, dynamic map data points into a Google Maps display. We want to be able to update a location and have it almost immediately display on our website. If you’d like to read more about why this is important, here’s my introduction.

Working Example: The example we’ll be using is shown here.

Github / Code Repo: For those who find it useful, the public github repo is here.

Along the way, I’ll share couple of tips on some security considerations, along with helpful observations which will hopefully save you many hours of troubleshooting. The full list of episodes can be found at the bottom of each episode.

As always, I hope this content is helpful. It means the absolute world to me when you take time to clap for an episode, subscribe to my stories or use my referral link to sign up for Medium. It lets me know that my stories are helping you ❤️.

Enjoy, and feel free to drop me a DM on twitter, connect on LinkedIn / Github with thoughts and comments 😃

In This Episode

I’m super excited about this episode. We’ll finally be connecting our dynamic location data to our Google Map via the HTML Component.

By then end of this episode, you’ll be able to drop a map location into your collection and have it update on your map almost immediately. It’s a powerful capability which will have huge benefits for you and your customers!

Here’s what we’ll be covering:

Setting up our HTML Component to send and receive data
Setting up our Parent page to send and receive data
Integrating some troubleshooting functions which work with the Wix logging platform
Retrieving and Processing our map data
Giving it a quick trial — YAY!

Let’s get into it.

Setup HTML Component to Receive Data

As I covered in previous episodes, an HTML Component is effectively a webpage within a webpage. It’s an odd concept to get your head around, so if it’s bending your brain a bit, I totally understand. I also don’t really have a solution for the conceptual part of it, it’s a bit inceptionish (not a real word).

Anyways, this means that to get information to and from our HTML Component, we have to send and receive messages from the parent page. In the next section, we do the exact same thing with the parent page.

A Quick Warning

As I discuss in a previous episode, there are a few issues with HTML Components (iFrames). Previously I cover a little about the security implications, today, just be aware that messaging between your parent site and an HTML component can often be a bit problematic.

In this episode, we’ll be coming across a few things to be aware off:

When sending a message from your HTML Component -> Parent page, you need to specify a destination URL. Lazy programmers will simply use a "*" designation…but doing this makes it possible for malicious entities to intercept the message. Security best practice is to always specify your destination URL even if the message has no security value. Trust me, it will save you a TON of heartache in the future!
When you setup your HTML Component to receive messages, the default behaviour is to receive ALL messages. This means you may receive messages from other iframes (HTML Components) on your webpage. For instance, if you’re running Google Chrome and the MetaMask Crypto Wallet, you’ll suddenly see yourself receiving messages from MetaMask checking that it’s still working (yes, that is a security issue all by itself). In this episode, we will be filtering our messages based on the target variable we configured in episode 2.

HTML Component Message Receive Code

Our first stop is to set up our HTML Component to Send a message. This is pretty straightforward, using a modified version of code from a Wix Velo tutorial. Do the the following:

Navigate to your HTML Element and select ‘Edit Code’
Navigate to the second <script> tag
Within the function initMap() insert the following:

You can see here where we have immediately filtered the incoming messages based upon the target we set in Episode 2.

Update your code, and while nothing should happen, we can be excited that we’re now receiving messages!

Setup HTML Component to Send Data

The next component of our messaging system is to send a message from our HTML Component -> Parent page. As discussed earlier, we always want to make sure that we are clear about what URL to send our message too, as this prevents the message from going to unintended (ahem, particularly when this is malicious) recipients. We’ll also use this as an opportunity to start building our troubleshooting solution, covered more extensively later.

Get the Parent Page URL

We’ll be using a programmatic method to get our URL. This has several benefits.

It will work in the Wix Editor and our Live Site
It’s far simpler to implement at scale
We can include some error checking to make sure that it is indeed an iframe

To do this, we implement the following:

In our second <script> tag create a function just above the window.initMap = initMap; called getParentURL();
At the top of the script create a variable to store the URL: myURL = "null"
Below this, set the myURL variable: myURL = getParentURL(); (you could easily combine lines 2 and 3 together, I separated simply to demonstrate my point)
Fill in the getParentURL() function with the following:

Press ‘Update’ and continue.

Create the Send to Parent Functionality

With our URL specified, we’re now going to create our page messaging. We’ll use this opportunity to set up our trouble shooting function. Implement the following below the getParentURL() function you just created:

Press ‘Update’ and continue.

Setup Parent Page to Send Data

Next we move to setting up the Parent page to send data. To do this, use the HTML Element name you created in Episode 1 (mine was googleMapsFrame ). Here’s the function to implement under your $w.onReady function on the main page

Setup Parent Page to Receive Data

Now we’re going to setup our Parent Page to receive data from our HTML Element. In this part of our code, we want a way to differentiate the following:

A command message, which we’ve called cmd
A debug message, which we’ve called debug

This allows us to differentiate between the ability to instruct our page to do something (a command ) vs updating us on the site’s progress ( debug ). To do this we’re going to implement a couple of switch statements to allow some basic logic branching to occur.

Firstly, we need to let our page know what to do with incoming messages. This is done within the $w.onReady function, so update your $w.onReady function to look like this:

Next, we need to implement the function which will process the message. Implement this function under your $w.onReady function:

If you look carefully, you might notice that an exciting thing has occurred. We’ve included a function called retrieveLocationData() which fires when we receive a cmd from our HTML Frame. You can see it on line 11!

This is pretty exciting, so let’s implement that function now!

Retrieve Location Data

This function calls our backend code from Episode 2. It’s the first time we’ve breached the dynamic wall -> retrieving data from our collection and piping it to our live page.

Because of the work we’ve done previously, we only need a few lines of code:

Import the function we created previously by placing this line above the $w.onReady function: import {getLocationData} from 'backend/queryLastTenLocations'
Add in this code below the $w.onReady function

Did you notice what this function does? It retrieves our location information and sends it to our HTML Frame!

How good is that! We’re really making progress now!

Process Received Data in HTML Frame

The next step is to process our received data in the HTML Frame. If you’d like to follow the data format, here’s the link.

Effectively we need to undertake the following steps within our initMap function:

Handle a ‘no location’ length, which will happen when the HTML element is initialised. If it happens, send a command to the parent page to update the locations
When event data is received, extract the midpoint
Extract the midpointLocationfrom the midpoint
Update the locations array with the extracted locations
Initialise the Google Map
Plot our midpoint marker
For each location, extract the position
Plot each location

This is quite the process to go through 😅, so here’s the code to update:

It’s Time to Try It Out!

Let’s take a moment to celebrate our progress!

If you publish your website and have a look at it, you should be able to see some movement.

Nice work!

However, if you look a bit closer, you might notice a few issues:

Adding a new location to our collection doesn’t update the map
The zoom level of the map doesn’t auto update. If a marker is placed too far away from the midpoint, it isn’t visible in the frame

These are great observations and exactly what we’ll cover off in our next and final episode.

Wrapping Up Episode 4

What an amazing episode! We’re finally displaying markers from our various locations and it’s looking great! You’ve done so well.

We covered a ton of stuff in this episode, with a lot of code. You’ve really done a great job getting this far. As always, I really appreciate you working through this. If it’s helped you and been valuable, please consider dropping me a clap or subscribing to my email distribution.

In our final episode we’ll finishing our series with the display of a beautiful and complete map which updates dynamically.

List of Episodes:

The full list of episodes in this series are linked below to help you navigate quickly ❤