Google maps component - programmatic script/lang change

[Ketec]

Feature Description

Right now you would have to add key, lang etc into index.html manually.
What it should allow, is to add a init service that can be used to inject the API with params (key, client, language, libraries).
It should also handle wiping all map scripts + loaded library to trigger language change.

Right now this has to be implemented manually, but it should be part of the package.

Use Case

Allows loading maps from configurations that may come from the server-side (key, libraries etc).
Allows changing language without page reload (transloco for example).

[mbehrlich]

This is definitely something I'd like to implement. I will look into this.

[Ketec]

This is how I currently deal with dynamic lang + script. Init is called from angular app initializer.

async init(): Promise<void> {
    // Trigger location prompt if user has not accepted yet
    await navigator.geolocation.getCurrentPosition( () => {});

    // Reinitialize on language change
    this.preferencesService.getLanguage().subscribe(lang => {
      this.setGoogleMapsApiScript(lang).then( () => {
        // Maps API callback
        window['mapInit'] = () => {
          this.mapInitialised$.next(true);
        };
      });
    });
  }

  private async setGoogleMapsApiScript(lang: string): Promise<any> {
    // Delete any existing maps api instance and script to reload language
    document.querySelectorAll('script[src^="https://maps.googleapis.com"]').forEach(v => {
      v.remove();
    });

    // Delete existing loaded map scripts
    if (typeof google !== 'undefined' && typeof google.maps !== 'undefined') {
      delete google.maps;
    }

    const appConf = this.configurationService.getConfig();
    // Init new maps api
    const script = document.createElement('script');
    script.id = 'googleMaps';
    script.async = true;
    script.defer = true;

    script.src =
      'https://maps.googleapis.com/maps/api/js?client=' +
      appConf.google_maps.client_id +
      '&key=' +
      appConf.google_maps.key +
      '&callback=mapInit' +
      '&libraries=' +
      appConf.google_maps.libraries.join() +
      '&language=' +
      lang;

    document.head.appendChild(script);
  }

This requires another step - I have to listen for the init and inject the google-maps component dynamically so I can refresh the view - can likely be handled within the maps component itself.

[Akxe]

While this approach is good, it has it's pitfalls too. Google Maps API should loading as soon as it is needed, Thus if it is in the initial view, waiting for JS to parse before starting would be quite a slowdown. Also if someone decides to include it in the initial view, we should look if it is present to either warn xor prevent loading.

[Ketec]

Yes, this is a relatively quick version of this to get it working.
APP_INITIALIZER should be called before bootstrapping the AppModule and since the script is async, it would load while the rest of the app is bootstrapped.

I also used the mapInitialised$ observable that can be listened to inject the map (had to use dynamic comp to reload the map on lang change - but the map refresh should be part of the component).

It's just unfortunate google maps still does not allow passing lang, key, clientid and libraries to the API after the first script is loaded.

But they still rely on the poor user experience of having to full reload or hacks like this to reload scripts.

[Akxe]

@Ketec

Yes, this is a relatively quick version of this to get it working.
APP_INITIALIZER should be called before bootstrapping the AppModule

Yes, and no... It should only run, if (at least) one of google maps components is being used.

I think that there should be a service, that will have ReplaySubject with google map API. This observable will look if google.maps is defined, and if not check scripts, if it is loading, and if either, start downloading on its own. This way you can have google maps script inline in head if you want while being able to fall back.

Also, why not use dynamic import for the map?

[Ketec]

Dynamic import to replace what, dynamically injected component?

Also checking the existing script only works for one-time load where parameters to the API do not change.
Like language or libraries - for those you need to delete the scripts, delete any loaded js for maps and reinject with new parameters.
They do not support loading/changing those through API.

And reloading the entire page on language change is a ancient, anti-user experience way to do things.

[Akxe]

Wow... That's irratating. Woundt be better to create iftame with API and get cross site reference, or something like that, it should work as long as it is on same domain

[Ketec]

I did go for a bit simpler approach instead of dynamic component -
I am calling ngOnInit() again after I have reloaded gmap scripts to refresh this component.
It's a bit too much but the required parts (like event manager) is private.

If the component had a method to call to reinitialize, this would be better.

Ideally, this reinitialize step should also be handled inside the component.
But the question is how it should all be solved.

1. Script insertion should be dynamic.
2. It should support dynamic parameters - API key, clientId, libraries and language.
3. Language can change during runtime without page reload (ex transloco or ngx-translate) - the component/service needs a lang input for that.
4. To update lang, existing scripts and loaded maps API need to be deleted and recreated.
5. Option to use service from angular initializer or lazy when needed.

[Akxe]

Why does it actually need to be deleted? Won't Google map override the previous language?

[Ketec]

If you look at the maps API during load - it injects a number of new scripts into your HTML by itself.
If you don't delete them - you would get duplicates added, bloating and potentially causing conflicts.

And if you don't destroy the old instance it seems it won't properly clear it itself:
You have included the Google Maps JavaScript API multiple times on this page. This may cause unexpected errors.

[mbehrlich]

Although it would certainly be convenient to provide an easy way to load the API, right now we don't want the google-maps components to be in charge of loading a separate API and either inserting the Google Maps JavaScript API scripts into our user's pages or having to load the API using a jsonp request. I'm closing this for now.